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Section  1 

Introduction 

Public  Law  102-396,  Section  9070  of  the  Department  of  Defense  (DOD) 
>^ropiiations  Act,  1993,  enacted  on  6  October  1992,  requires  that,  "where 
cost-effective,  all  Department  of  Defense  software  shall  be  written  in  the 
programming  lyngnaga  Ada  . . . The  Department  of  the  Navy  (DON)  prepared 
this  second  edition  of  Ada  Implementation  Guide  to  help  Program  Managers  and 
their  staffs  to  implement  this  law.  (For  the  purposes  of  this  document,  the  terms 
Program  Managers  and  Project  Managers  are  synonymous.) 

New  additions  to  this  guide  include  the  following: 

•  Software  engineering  and  Ada  training  requirements 

•  Information  on  standard  Ada  binding  to  commercial  application  software 

•  A  section  on  the  way  Ada  facilitates  the  application  of  software  engineering 
principles 

•  Integration  of  Ada  and  new  emerging  technologies  (e.g.,  open  interns 
architecture,  software  reuse,  computer-aided  sofnvare  engineering, 
reengineering) 

•  A  DOD/DON  Software  Poli^  Matrix  that  includes  policy  descriptions  and 
related  policies. 

LI  SCOPE  OF  Ada  USE 

Ada  was  developed  to  control  the  proliferation  of  programming  languages,  establish 
a  standard  programming  language  for  DOD,  and  reduce  DOD’s  cost  to  maintain 
software  for  its  mission-critical  systems.  Congress  has  recognized  Ada  as  the 
standard  for  all  DOD  software  application  development  and  has  mandated  its  use 
unless  an  alternative  approach  can  be  demonstrated  to  be  cost-effective  over  the 
application  life  cycle.  As  a  matter  of  DOD  poli^,  all  new  systems  and  major 
software  upgrades  are  subject  to  this  mandate.  The  mandate  to  use  Ada  iqiplies  only 
to  software  that  DOD  is  developing  and  must  support  and  maintain  throughout  the 
life  cyde.  Organizations  are  encouraged  to  use  Commercial-Off-The-Shelf  (COTS) 
software  to  fidfill  operational  requirements  as  development  tools  and  even  support 
libraries  within  an  application.  The  language  used  for  these  artifacts  is  immaterial 
because  DOD  does  not  maintain  the  sof^rare.  When  DOD  does  maintain  the 
software,  however,  the  language  does  matter,  and  DOD  must  have  an  infrastructure 
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to  provide  cost-effective  maintenance  and  supportability  of  the  software  over  the 
^tem  life  cycle  to  include  Post-Deployment  Software  Support  (PDSS).  Use  of  a 
single  DOD  language  to  support  this  infrastructure  is  not  a  new  concept:  DOD 
organizations  have  required  the  use  of  particular  languages  since  the  1960s;  in  the 
mid-1970s,  the  use  of  a  smaller  set  of  languages  was  mandated  for  DOD  applications; 
in  1985,  the  use  of  Ada  was  mandated  for  a  dass  of  DOD  systems;  and  in  1990,  the 
Congressional  mandate  made  Ada  the  standard  language  for  all  DOD  systems. 

This  guide  addresses  Ada  policy  implementation  for  two  broad  classes  of  DON 
systems:  Mission-Critical  Computer  Resource  (MCCR)  ^tems  and  Automated 
Information  Systems  (AIS).  The  term  MCCR  is  used  in  this  guide  to  denote  the 
dass  of  systems  managed  under  the  DODD  5000  series  of  instructions.  The  term 
AIS  is  used  to  denote  those  systems  managed  under  the  DODD  8000  series  of 
instructions.  The  communities  of  program  managers  who  manage  these  systems  have 
distinctly  differing  environments  for  implementing  Ada  poliq^. 

The  MCCR  community  consists  of  organizations  that  work  on  computer  resources 
critical  to  the  conduct  of  the  militaiy  mission  of  the  DON,  including  those  for  all 
tactical  and  strategic  weapons,  communications,  command  and  control,  cryptologic 
activities  related  to  national  security,  and  intelligence  systems  that  directly  support 
mUitary  operations.  Such  systems  often  are  embedded.  The  MCCR  community  has 
been  developing  software  systems  in  Ada  since  1985;  however,  most  systems 
development  has  been  contracted  to  the  private  sector. 

The  AIS  community  comprises  organizations  that  work  on  business  computer 
resources  that  are  not  mission  critical,  including  all  administrative,  logistics,  financial, 
personnel,  and  work  load  planning  tystems.  Such  systems  may  operate  on 
microcomputers  or  mainframe  computers  in  a  stand-alone  or  networked  mode.  The 
AIS  community  has  developed  its  software  systems  in  a  variety  of  High  Order 
Languages  (HOLs)  Ity  using  inhouse  DON  personnel.  Although  relatively  few  AIS 
applications  systems  have  been  developed  in  Ada,  the  number  is  increasing  as 
activities  and  claimants  are  developing  Ada  expertise. 

Whether  the  system  is  MCCR  or  AIS,  Ada  must  be  used  during  the  concept 
exploration  and  definition,  demonstration  and  validation,  engineering  and 
manufacturing,  development,  and  production/deplttyment  phases  of  a  tystem  and  for 
both  application  and  support  software.  In  addition,  Ada  must  be  used  for  major 
modifications  to  existing  tystems  and  for  tystems  that  involve  integrating  components 
into  systems  that  incorporate  commercial  and  other  nondevelopmental  softw^e.  To 
use  an  alternative  programming  language,  a  waiver  must  first  be  obtained  from  the 
appropriate  waiver  authority;  the  waiver  must  include  an  economic  analysis  that 
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dearfy  delineates  that  an  alternative  -roadi  will  be  significant^  more  cost- 
effective. 

L2  EXPERIENCE  OF  Ada  USE 

Operation  Desert  Storm  iliiistrates  why  DOD's  use  of  a  single  HOL  is  appropriate. 
During  this  conflict,  the  Air  Force’s  Theater  Display  Terminal  (TDT)  had  been 
depleted  to  Israel  to  warn  of  Iraqi  SCUD  attacks.  The  TDT  is  a  d^lo3rable  missile 
warning  ^tem  written  in  Ada  for  a  Sun  3  UNIX  environment  On  11  January  1991, 
Israel  identified  a  new  ^tem  requirement  for  the  TDT  operational  program,  namefy, 
to  identify  the  country  of  origin  for  a  missile  launch.  Knowing  the  country  of  origin 
was  considered  important  in  formulating  the  tactical  response.  To  Israel,  it  made  a 
Hifffwngo-  whether  a  SCUD  was  launched  from  Iraq  or  from  some  other  country. 
By  13  January  1991,  an  existing  country-of-origin  algorithm  in  Ada  and  an  Ada 
geopolitical  were  found.  On  13  January  1991,  these  artifacts  were 

integrated  into  a  developmental  system;  on  14  January  the  enhancement  was 
integrated  into  an  operational  ^tenL  The  software  was  flown  to  theater  and 
installed  for  use  on  15  January.  On  16  January,  onfy  S  days  after  the  requirement 
was  identified,  the  new  capability  was  rearfy  to  detect  Iraqi  SCUD  attacks  on  Israel 
The  capability  to  support  this  new  mission  requirement  rapidly  was  possible  only 
because  the  TDT,  the  country-of-origin  algorithr^  and  the  geopoUtical  database  were 
in  Ada.  Integration  of  these  artifacts  was  pc»sible  only  because  of  the  Ada  package, 
which  provided  dean  logical  interfaces  between  each  artifact  Had  Ada  not  been 
used,  the  cost  to  support  the  new  requirement  would  have  been  substantial,  and  the 
enhaocement  would  not  have  been  fielded  by  the  end  of  Desert  Storrrt 

Today,  use  of  Ada  enables  DOD,  govermnent,  and  commercial  organizations 
committed  to  Ada  to  achieve  a  higher-quality  product  at  reduced  life-^de  costs. 
Just  as  Ada  use  makes  sense  to  DOD  for  sound  economic  reasons,  its  use  also  mak^ 
sense  to  the  conunerdal  world  for  the  same  reasons.  Among  the  corrqranies  that  are 
using  Ada  are  Digital  Equipment  Corporation,  Boeing,  Motorola,  and  RodcwelL 
Boeing’s  777,  the  Federal  Aviation  Administration’s  Adt^ced  Automation  System, 
and  the  National  Aeronautics  and  Space  Administration’s  Space  Station  are 
non-DOD  projects  committed  to  the  use  of  Ada.  These  organizations  are  openfy 
embracing  Ada,  not  because  of  the  Ada  mandate,  but  because  using  Ada  to  produce 
hi^-quality  software  for  large,  safety-critical  iqrplications  is  a  sound  economic 
business  dedsiorL 

Boeing  is  an  excellent  example  of  a  conunerdal  organization  committed  to  using 
Ada.  The  Boeing  777,  with  its  estimated  10  million  lines  of  code,  will  be  one  of  the 
largest  software  projects  ever  undertaken.  Boeing  expects  to  take  advantage  of 
software  reuse  Ity  reusing  2  to  4  million  lines  of  existing  code.  Boeing  also  used  Ada 
on  the  recent  modification  to  the  Boeing  747,  which  is  now  flown  extensivefy  by  the 
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airlines.  Boeing  is  conunitted  to  the  use  of  Ada  for  this  ^tem  because  of  the 
quality,  cost,  and  schedule  benefits  provided  when  Ada  is  used  in  combination  with 
modem  sofhvare  engineering  practices. 

Data  obtained  by  comparing  the  B-52  Offensive  Avionics  System  (OAS)  Modification 
in  1979-1980  and  the  F-22  Advanced  Tactical  Fighter  (ATF)  Demonstration 
Evaluation  (DEMVAL)  in  1990  he4>ed  Boeing  decide  to  commit  to  Ada  on  the  777. 
The  B-S2  OAS  was  written  in  120,000  lines  of  JOVIAL  source  code.  Originally, 
about  15  flights  bad  been  scheduled  to  test  the  software.  During  flight  testing,  more 
than  800  problem  reports  were  identified,  and  iq>proximately  80  flights  were  required 
to  complete  the  software  testing.  Testing  was  unnecessarily  complicated,  expensive, 
and  problematic  because,  on  average,  30  to  SO  patches  were  entered  into  the  tested 
software.  In  contrast,  the  F-22  ATF  was  written  in  250,000  lines  of  Ada  source  code. 
This  represented  far  more  than  twice  the  complexity  of  the  B-52  OAS  because  Ada 
is  capable  of  dealing  vrith  high-level  abstractions.  Thirty-one  flights  had  been 
sdieduled  to  test  all  the  complexities  of  the  flight  software.  Only  eight  problems 
were  identified  against  the  fli^t  software.  This  represents  an  improvement  of  two 
orders  of  magnitude  from  the  B-52  OAS  to  the  F-22  ATF  DEMVAL  Testing  was 
facilitated  because  a  dean  compile  was  available  as  required  because  of  Ada’s 
support  of  separate  compilatioiL  These  statistics  are  even  more  impressive  given  that 
seven  different  contractors  developed  the  ATF  software  and  a  team  of  programmers 
integrated  it  at  the  flight  test  site  the  week  before  the  first  flight  Certainty  the 
advances  in  software  engineering  and  tools  between  1980  and  1990  played  a  role  in 
these  statistics.  The  support  of  these  software  engineering  advances  and  tools  for  the 
Ada  language  was  an  important  factor  in  Boeing’s  conunitment  to  Ada  for  the 
Boeing  777. 

L3  DOCUMENT  SCOPE 

This  document  is  intended  to  guide  Program  Managers  in  using  Ada  in  systems 
development  throughout  the  various  phases  of  acquisition  and  to  promote  the  use  of 
sound  software  engineering  ptindples,  concepts,  and  processes  in  systems 
engineering.  All  levels  of  management,  technical  persoimel,  and  the  tystems 
development  conununity  should  refer  to  the  information  contained  herein. 

The  intent  is  to  update  this  document  bieimially.  In  keeping  with  the  spirit  and 
intent  of  the  document,  all  users  of  this  guide  are  encouraged  to  share  their 
experiences  and  knowledge  with  the  Ada  community.  Therefore,  if  a  reader  finds 
that  significant  areas  are  not  covered  in  this  document,  we  request  that  he  or  she 
provide  feedback  to  the  document  update  process  so  that  the  next  user  will  have 
better  information.  (See  ^rpendix  A,  Section  A.1.1,  DON  Ada  Representative 
address.) 
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1.4  CONTENT  VND  ORGANIZATION  OF  THIS  DOCUMENT 
This  two~volume  document  discusses  the  use  of  Ada  for  software  ^tem  development 
in  the  DON,  and  its  contents  apply  to  both  AIS  and  MCCR  communities.  Volume  I 
contains  eight  sections,  a  glossary,  a  list  of  acronyms  and  abbreviations,  a  reference 
list,  a  bibliography,  and  an  index.  Section  1  provides  information  on  the  content  of 
this  document.  Section  2  describes  DON  poli^  with  regard  to  Ada  use.  Section  3 
<viT^taiiw  specific  guidance  on  incorporating  Ada  into  all  phases  of  life-^de 
management— from  program  plarming  through  post-deployment  maintenance.  In 
Section  4,  the  environments  that  support  development  and  maintenance  of  Ada 
application  software  are  described.  Section  5  addresses  the  concept  of  software 
engineering  and  identifies  several  Ada  features  that  are  important  in  supporting 
software  gnginftftring.  Section  6  presents  a  series  of  lessons  learned  relevant  to  the 
software  development  process,  and  Section  7  highlights  what  DON  Program 
Managers  can  expect  in  the  future.  Section  8  contains  information  on  recommended 
training  in  Ada  and  software  engineering  for  DON  software  professionals. 

Volume  n  contains  several  appendixes  that  provide  valuable  information  to 
supplement  the  guidance  contained  in  Volume  I.  Appendix  A  describes  additional 
resources  that  will  be  helpful  to  Ada  Program  M^gers  and  u^^rs.  As  noted, 
y^pendix  B  provides  a  matrix  of  DOD/DON  software  policy.  The  o  .er  appendixes 
expand  on  issues  discussed  in  Volume  I,  and  they  are  referenced  where  appropriate. 
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Ada  Policy 

This  section  summarizes  the  Department  of  the  Navy  (DON)  policy  on  Ada  use  in 
Automated  Information  Systems  (AK)  and  Mission-CMtical  Conqiuter  Resources 
(MCCR)  programs. 

2.1  POUCY  DIRECTIVES 

Public  Law  102-396  requires  that,  "notwithstandioig  any  other  provision  of  law,  after 
June  1,  1991,  where  cost  effective,  all  Department  of  Defense  software  shall  be 
written  in  the  programming  language  Ada,  in  the  absence  of  special  exenqjtion  by  an 
official  designated  by  the  Secretary  of  Defense.*  Figure  2-1  provides  the  directhres 
and  instructions  that  serve  as  the  framework  for  DON  implementation  of  this  law. 

2.2  POUCY  RATIONALE 

The  thrust  of  the  Department  of  Defense  (DOD)  conqmter  programming  langiiag#. 
poli^  has  been  to  limit  the  munber  of  different  conqmter  languages,  including 
dialects  and  support  tools,  associated  with  the  application  software  maintained  by 
DOD.  DOD  estimates  that  maintenance  accounts  for  60%  to  S0%  of  software  life- 
cycle  costs;  therefore,  DOD  emphasis  is  on  one  High  Order  Language  (HOL)  and 
a  limited  set  of  standard  HOLs. 

The  selection  of  Ada  as  the  "single,  common,  i^roved  standard  HOL*  for  DOD 
^tems  was  based  on  the  inherent  software  engineering  features  of  the  Ada 
programming  language.  These  software  engineering  features  lead  to  software 
programs  that  are  better  structured,  less  error  prone,  and  more  easity  maintained, 
hi  addition,  these  features  facilitate  reuse  and  ^tem  reengineering.  Ada  and  Ada 
Program  Siqiport  Enviromnents  (PSEs)  enable  DOD  to  deal  effective^  with  the 
prt^rammatic  and  technical  challenges  posed  by  the  increasing  number  and 
conq>lexity  of  software-intensive  ^tems. 
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flgBre  2-1.  DON  Dimthcs  and  lastnctitiBi  far  tatpIcBcatlBg  Fablic  Law  102496 

23  POUCY  DESCRIPTION 

Table  2-1  provides  a  description  of  the  essential  features  of  DON  Ada  policy  as 
planned  to  be  issued  in  SECNAVINST  52343A.  The  table  has  been  prepared  with 
the  eiqiectation  that  the  SECNAVINST  S2343A  will  be  issued  at  about  the  time  this 
guide  is  promulgated.  Although  the  table  has  been  constructed  to  be  consistent  with 
SECNAVINST  52343A,  in  the  event  of  conflicts,  the  provisions  of  SECNAVINST 
52343A  take  precedence.  Appendix  B  provides  additional  information  on 
DOD/DON  instructions  related  to  Ada,  software  engineering,  and  life-tyde 
management  poli^. 
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Table  2-1.  DON  Ada  PoUcy  ImpIcmcntatioB  Matrix 


AREA 

Ada  POUCY  DESCRIPTION 

COMMENTS 

Scope/ 

This  iiistniction  q)plies  to  all  systems  and 

Mqor  software  upgrade  is 

Applicability 

software  that: 

defined  as  "a  diange  to  the 
system  architecture  which 

(a)  are  managed  under  SECNAVINST  S200.32A, 

would  resuh  in  a 

or  (DOD  5000  Series) 

cummuladve  one-third 
modification  to  a  computer 

(b)  are  managed  under  SECNAVINST  523 1. 1C, 

software  configuration 

or  (DOD  8000  Series) 

item  (DOD-STD-2167A) 
or  a  subsystem 

(c)  are  part  of  Science  and  Technology  (SAT) 

specification  (DOD-STD- 

programs  under  directimi  and  oversight  of  the 

7835)  within  any  five  year 

Office  of  the  Chief  of  Naval  Research  (OCNR). 

period  as  measured  in 
compileable  source  lines  of 

This  instruction  does  ncrt  apply  retroactively  to  die 
following: 

code. 

Modification  includes 

•  Systems  that  have  entered  producdmi  and 

addition,  deletion,  or 

d^loyment  (passed  Milestone  HI)  for  (a) 

change  exclusive  of 

above. 

•  Systems  managed  under  (b)  above  that 
have  passed  Milestone  11  as  of  1  June  1991 

*  Systems  managed  under  (a)  above  for 
which  a  documented  language  commitment 
was  made  in  accordance  widi  previous 
policy. 

routine  maintenance." 

This  policy  does  apply  at  die  first  major  software 
upgrades  for  diese  systems. 

This  policy  supersedes  SECNAVINST  52342. 
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AREA 

Ada  POUCY  DESCRIPTION 

COMMENTS 

Existing 

Operati<mally 

Fielded 

Software 

Ada  is  not  required  for: 

Software  maintenance  limited  to  error  correction 
and  modifications  for  portability  of  existing 
softvrare. 

Reuse  or  upgrade  of 
operationally  fielded 
software  for  new 
acquisition  programs  or 
majOT  software  upgrades  is 
addressed  below. 

Nondeliverable 

Software 

Ada  is  not  required  for  the  development  of 
nondeliverable  software,  as  defined  in  DOD-STD- 
2 167 A,  does  not  require  Ada. 

Ratimiale:  By  definition, 
nondeliverable  code  will 
not  be  delivered  to  or 
maintained  by  TOD. 

COTS 

Software 

■  No  waivers  are  required  for  the  use  of  COTS 
software,  including  operating  systems,  utilities, 
libraries,  self-contained  applications  programs,  and 
vendor  update  implementations. 

The  COTS  software  is  not  to  be  modified  in 
function  or  nuintained  by  die  goverment. 

Use  of  COTS  software  is 
encouraged  and 
recommended. 

Reuse  of  Ada 
code 

No  waiver  is  required. 

Reuse  of  Ada  software  is 
encouraged  and 
recommetided. 

Reuse  and 
Upgrade  of 
Existing  DOD- 
and 

Government- 

maintained 

Software 

No  waivers  are  required  for  reuse  of  modification 
of  existing  operationally  fielded  non-Ada  software, 
as  long  as  the  change  to  the  reused  or  modified 
software  is  less  than  a  nuyor  software  upgrade. 

Changes  to  existing  software  that  constitute  a 
major  software  upgrade  must  be  done  in  Ada  or 
else  a  waiver  is  required. 

Major  software  upgrade  is 
defined  above. 
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Table  2-1.  DON  Ada  Policy  Implementation  Matrix 
(continued) 


AREA 

Ada  POLICY  DESCRIPTION 

COMMENTS 

Advanced 

No  waivers  are  required  for  the  use  of  a 

ASTs  include  life-cycle 

Software 

conunerciaily  available  oir-the.shelf  AST  that  is 

support  tools. 

Technology 

not  modified  or  maintained  by  the  Government. 

programming  support 

(AST) 

environments,  non- 

•Note; 

procedural  languages 
(4GLs),  and  modem 

Use  of  SQL  (ANSI.  FIPS  127-1)  with 

DBMSs.  Although  the 

compliant  COTS  DBMS’s  for  binding  to 

native  commands 

Ada  host  applications  is  an  Ada  policy 

associated  with  ASTs  may 

compliant  qrproach.  The  software 

be  used  for  ad  hoc  query 

engineering  approach  for  constructing  such 

transaction,  any  programs 

DBMS  applications  is  described  in; 

written  for  use  with  the 

•  SEI88-MR-9 

AST  or  HOLs,  or  used  in 

-  SEI89-SR-I4 

conjunction  with  AST 

-  SEI90-TR-26 

must  use  Ada  or  Ada 
bindings. 

Waiver 

Authority 

As  specified  in  SECNAVINST  S2342A. 
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Sections 

Implementation  Guidance 

To  gapteliM  on  the  benefits  of  software  engineeruig  with  Ada,  the  Program  Manager 
must  carefully  plan  for  its  use  throughout  the  program  life  ^de.  Department  of  the 
Navy  (DOI^  programs  have  m^tq>le  st^es:  plann^  acquisition  and/or 
development,  test  and  evaluation,  and  Post-Deploymem  Software  Support  (PD^). 
It  is  critical  that  the  Ada  softwue  engineering  process  be  assimilated  into  the 
project’s  systems  eogineeriqg  activities  at  the  earliest  possible  time.  This  combination 
of  ^tems  engineering  and  Ada  will  provide  the  Program  Manager  with  tangible 
benefits  su^  as  higher  quality  software,  fewer  tystem  integration  probleuB,  ease  of 
post<deployment  maintenance,  and  software  reusability— all  of  w^di  result  in 
reduced  life<yde  costs. 

This  section  provides  guidance  to  heh>  Program  Managers  effectivety  engineer  and 
incorporate  Ada  into  their  programs.  It  discusses  the  interrelated  elements  of 
program  planniog,  acquisition  planning,  tystems  eogineeripg,  and  risk  management 
It  is  inqmrtant  that  the  Program  Manager’s  acquisition  and  program  planning  reflect 
systems  engineering  (Le.,  an  integrated  approa^  to  hardware  and  software)  from  the 
first  stages  of  the  acquisition  process. 

This  section  assumes  that  the  Program  Manager  is  well  versed  in  the  areas  of 
software  and  tystems  engineering  and  the  ^ropriate  Department  of  Defense 
(DOD)  and  DON  polity  and  directives. 

3.1  PROGRAM  PLANNING 

To  effectivety  incorporate  Ada  into  tystems  development,  the  following  areas  must 
be  addressed: 

•  Organizational  structure 

•  Cost  estimation 

•  Resource  planning. 

The  Program  Manager  is  reqxmsible  for  ensuring  that  program  planniqg  thoroughly 
addresses  these  key  areas.  It  is  critical  that  the  acquisition  strategy  fully  integrate 
software  and  hardware  systems  development  as  earty  as  possible  in  the  process. 

3.L1  Organizational  Structure 

Ada  software  develq[>ment  and  maintenance  efforts  are  conq>atible  with  all 
off^mizational  structures  (Archer,  1991).  The  use  of  Ada  does  not  restrict  project 
size,  functional  organization,  combinations  of  organizational  structures,  or  the 
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function  of  the  organization  concerned.  As  a  matter  of  good  business  and  systems 
engineering  practices.  Program  Managers  should: 

•  Establish  their  Program  Management  Organization  and  organizational 
interfaces  including: 

-  Operational  users 

-  Test  and  evaluation  organizations 

-  Software  development  organizations  (contractor  and  organic) 

-  Organic  support  organizations  (e.g.,  warfare  centers,  life-C^de  Support 
Activities  [LCSAs],  design  programming  activities.  Software  Support 
Activities  [SSAs],  and  In-Service  Engineering  Agents  [ISEAs]). 

•  Ensure  that  Ada,  software  engineering,  domain-spedfic  architecture,  and 
engineering  expertise  are  available  within  their  management  and  support 
organizations. 

•  Ensure  that  organic  support  activities  have  established  internal  management 
practices  for  improving  their  software  engineering  capabilities.  Tbese 
management  practices  should  include  provisions  for  introductory  and 
continuing  Ada  and  software  engineering  training,  incorporation  of  Software 
Engineering  Institute  (SEI)  software  process  improvement  plans,  and  institution 
of  Software  Engineering  l^ocess  Groups  (SEPGs). 

•  Promote  the  use  of  Ada  and  ensure  that  Ada  poli^  requirements  are  known 
and  understood  within  the  management  and  support  organization. 

3.12  Cost  Estimation 

Department  of  Defense  Directive  (DODD)  5000.1,  Department  of  Defense 
Instruction  (DODI)  5000.2,  DODD  8120.1,  and  DODl  8120.2  require  that  ^tem 
life-^de  cost  estimations  indude  cost  forecasts  for  development,  procurement,  and 
support  Program  Managers  are  responsible  for  performing  and  submitting 
developmental  and  support  cost  estimates  for  their  ^tems.  These  cost  estimation 
data  are  used  to  prepare  Program  Objective  Memorandum  (POM)  funding  estimates. 
Logistics  Requirements  Funding  Plans  (LRFPs),  Cost  and  Operational  Effectiveness 
Analyses  (OOEAs),  and  other  system  life-^de  milestone  decision  documents.  They 
serve  as  the  Government  estimate  for  contract  evaluations. 

As  DON  ^tems  have  become  increasingly  software  intensive,  software  costs  have 
become  a  significant  factor  in  overall  system  life-^de  costs.  Software  maintenance 
is  the  single  largest  life-cyde  cost  for  Government  computer  ^tems,  with  software 
development  costs  coming  next  Government  computer  ^tems  have  typically  been 
delivered  over  cost,  behind  schedule,  and  lacking  in  quality  and  maintainability. 
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It  is  crucial  that  accurate  software  cost  estimations  be  performed  to  provide  a  basis 
for  the  Program  Manager  to  plan  the  organization,  schedule,  and  resource 
requirements  needed  to  sustain  the  software  from  the  initial  software  development 
throughout  the  ^tern’s  life  Qrcle. 

One  of  the  most  challenging  tasks  in  software  management  is  to  accurately  estimate 
the  resource  requirements  and  time  needed  for  a  software  development  project 
Section  6,  Lessons  Learned,  notes  that  on  some  projects,  initial  plamiing  estimates 
for  software  development  understated  the  resource  requirements  and  time  needed 
and  severely  affected  actual  system  costs. 

The  three  generally  accepted  approaches  for  estimating  the  resources  and  schedule 
needed  for  software  development  are  as  follows: 

•  Comparing  the  proposed  project  with  a  completed  project  of  the  same  type  the 
cost  and  schedule  of  which  are  known 

•  Dividing  the  overall  development  effort  into  several  smaller  tasks  (often  using 
a  multilevel  Work  Breakdown  Structure  [WBS])  and  adding  up  the  estimates 
for  each  of  these  tasks.  (See  Softuure  Work  Breakdown  Structure, 
MH^STD-SSIB,  and  the  draft  Handbook,  MILrHDBK-171.) 

•  Using  a  software  cost  and  schedule  model  that  calculates  the  resources  and 
time  needed  as  a  function  of  other  software  parameters  (e.g.,  size,  complexity, 
function  points). 

Regardless  of  the  estimation  approach  used,  an  organization  with  more  e}q>erience 
in  developing  software  of  the  same  size  and  complicity  for  the  same  type  application 
will  produce  more  accurate  estimates  for  a  new  project.  Unfortunately,  estimates 
based  on  experience  with  small  and  less  complex  software  developments  are  almost 
always  unreliable  because  this  experience  cannot  be  applied  to  larger,  more  complex 
soft^^e  in  a  similar  application  area.  This  difference  results  partially  from  an 
ejqmnential  relationship  between  software  size  and  development  effort  E}q>erience 
in  one  application  area  does  not  always  transfer  well  to  other  application  areas. 

Many  software  cost  estimating  methods  have  evolved  over  the  years.  These  methods 
take  the  form  of  either  analog  or  parametric  models  and  may  be  implemented 
manually  or  by  using  automated  software  cost  estimating  tools.  Most  of  the  current 
models  reepure  size  estimates  of  either  the  lines  of  source  code  or  function  points  as 
input  The  resulting  estimates  for  cost,  effort  and  schedule  are  highly  dependent 
upon  the  accuracy  of  the  initial  size  estimates.  A  few  software  tools,  such  as  those 
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based  on  function  point  analysis  (Jones,  1991),  do  not  require  project  size  as  an 
iiqmt 

EjqMrience  has  shown  that  the  best  software  cost  estimates  have  been  based  on  an 
application  of  two  or  more  methods/models  by  eiqperienced  estimators.  The  Naval 
Center  for  Cost  Analysis  (NCA)  can  provide: 

•  Expert  advice  on  cost  estimation 

•  Assessments  of  software  cost  estimation  tools  being  considered  for  use  DON 

programs  (independent) 

•  Lessons  learned  from  cost  estimating 

•  Advice  on  estimating  software  development  and  maintenance  costs. 

Appendix  A,  Section  A.1.1,  provides  points  of  contact  and  addresses  of  organizations 
involved  in  cost  estimating,  and  ^)pendix  D  provides  additional  information  on  cost 
estimating. 

3.13  Resource  Planning 

The  major  areas  for  resource  planning  are  as  follows: 

•  Personnel  and  training 

•  Schedule  and  time 

•  Development,  test,  and  operational  environments  (hardware  and  software) 

•  Life-cycle  documentation 

•  Softwju-e  development  process  improvement 

•  Metrics 

•  Data  management  and  analysis 

•  Ufe-^cle  maintainability  (PDSS) 

•  Information  sources. 

The  subsections  below  discuss  these  areas. 

3.13.1  Personnel  and  lYaining 

The  Program  Manager  must  ensure  that  software  engineering  and  Ada  training  is 
conducted  at  all  levels  of  the  organization  (management  and  technical).  Project 
success  depends  on  the  ability  of  people  who  have  the  knowledge  rad  sk^  needed 
to  perform  the  system  rad  softv^e  engineering  fractions,  develop  the  process 
control  mechanisms,  collect  critical  data  rad  metrics,  rad  analyze  data  to  determine 
status  rad  trends. 
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Most  computer  science  graduates  who  are  trained  in  Ada  and  software  engineering 
principles  can  quickly  adapt  this  knowledge  to  a  specific  sqtplication.  Staff  members 
who  have  spent  years  working  with  traditional  programming  languages  and 
production  processes  may  require  additional  training  and  mentoring.  With  this 
aHHitinnni  training,  these  individuals  Can  become  a  valuable  part  of  the  program  by 
nring  their  inherent  knowledge  of  corporate  functions  and  e)q>erience  in  the 
application  ^nmain  Training  should  be  given  "just  in  time”;  that  is,  persoimel  should 
be  assigned  to  a  project  where  they  can  immediately  capitalize  on  their  training. 
Consideration  should  also  be  given  to  conducting  continuing  education  at  local 
universities,  via  membership  in  software  professional  societies,  and  at  software 
#>figini»r>riiig  and  Ada  symposia.  Appendix  A,  Sections  A.1.6  and  A3.4  provide 
information  on  Ada  professional  societies.  Section  8  in  this  volume  provides  detailed 
descriptions  of  the  contents  and  recommended  length  of  the  courses  available. 

3.U^  Schedule  and  Time 

Time  is  the  Program  Manager’s  most  important  consumable  resource.  Program 
Managers  must  identify  milestones  and  select  and  use  a  realistic  process  for 
measuring  progress  towards  achieving  those  milestones.  By  using  a  variety  of 
measures  to  track  progress  and  plan  contingenq^  actions.  Program  Managers  can  best 
mitigate  schedule  risk.  Although  cost  tracking  mechanisms,  such  as  WBSs,  can  be 
useful,  their  exclusive  use  does  not  constitute  a  valid  measure  of  progress. 

Program  Managers  should  be  aware  that  the  allocation  of  resources  to  a  schedule  is 
different  for  the  Design,  Coding,  and  Testing  Phases  of  a  project  when  using  Ada. 
In  general,  Ada  projects  require  more  time  for  design  and  less  for  coding  and  testing 
than  non<Ada  projects  because  errors  detected  in  the  Design  Phase  are  less  eiqiensive 
to  correct  Figure  3-1  depicts  the  results  of  a  National  Aeronautics  and  Space 
Administration  (NASA)  Study  that  analyzed  the  time  spent  on  the  various  phases  of 
Ada  and  non-Ada  projects  conducted  from  1983  to  1993.  As  shown  in  Figure  3-1, 
non-Ada  projects  typically  required  less  time  for  the  Design  Phase  and  more  time  for 
Coding  and  Testing  Phases. 

Time  invested  in  the  Design  Phase  reduces  the  time  required  for  the  Coding  and 
Testing  Phases,  and,  according  to  data  provided  Ity  NobelTech  (now  Celdus  Tech) 
of  Sweden,  it  also  reduces  time  needed  for  integration.  Figure  3-2  shows  the 
reduction  in  time  achieved  by  NobelTech  for  integratioa  In  the  past,  integration 
represented  about  40%  of  a  project’s  total  time.  When  NobelTech  used  Ada  on  its 
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Source:  NobefTech,  Sweden 

Figure  3^.  Reduction  in  Integmtion  Time 
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first  development  project,  the  integration  time  was  only  about  18%  of  the  total  time. 
Time  is  especially  important  during  ^tem  integration  when  many  subitems  must 
come  together,  often  for  the  first  time.  Delay  in  producing  a  critical  subitem  could 
seriously  affect  the  progress  of  other  subsystems.  Use  of  Ada  helps  to  reduce 
integration  problems  because  its  language  features  help  provide  a  clear  interface 
between  subitems.  Appendix  L,  Section  L.1,  contains  additional  information  on  the 
Ada  padcage  feature  that  provides  this  clear  interface. 

During  schedule  planning,  it  is  important  to  realize  that  time  invested  in  both  the 
requirements  and  design  phases  will  provide  significant  benefits  to  the  overall  ^tem 
life-^cle  costs.  Errors  in  the  Requirements  and  Design  Phases  are  ^ically  hi^  and 
are  the  most  costly  to  correct  Figure  3*3  shows  the  source  of  software  errors  as 
reported  in  the  Communications  of  the  Association  for  Computing  Machinery 
(ACM),  (Association  for  Computing  Machinery,  1984).  As  the  figure  shows,  more 
than  75%  of  errors  result  from  the  Requirements  and  Design  Phases.  Figure  3-4 
shows  the  relative  cost  to  correct  these  errors  based  on  a  study  from  AT&T,  Bell 
Laboratories,  1988.  A  requirement  error  detected  in  deployment  is  almost  an  order 
of  magnitude  more  expensive  to  correct  in  the  Deployment  Phase  than  in  the 
Requirements  Phase.  An  error  in  design  is  about  25%  less  expensive  to  correct  in 
the  Design  Phase  than  in  the  Deployment  Phase. 

As  illustrated  in  the  NASA,  NobelTech,  and  other  studies,  the  use  of  Ada  and 
software  engineering  results  in  the  early  detection  of  design  and  requirement  errors, 
thus  reducing  overall  life-^cle  costs.  Figures  3*3  and  3-4  also  imply  a  Program 
Manager  should  invest  additional  time  in  developing,  analyzing,  and  validating 
requirements.  Many  projects  would  have  benefited  from  a  more  rigorous 
Requirements  Phase. 

3.13J  Development,  Test,  and  Operational  Environments 
Software  and  software  development  methods  within  DON  must  keep  pace  with  the 
latest  development  and  test  technology.  The  Program  Manager  is  responsible  for 
ensuring  that  new  technology  is  identified,  evaluated,  and  integrated  into  the 
acquisition  process  when  it  provides  a  better  system  solution.  To  minimize  program 
risk,  only  those  technologies  that  have  been  folly  proven  and  demonstrated  should 
be  adopted  for  Full-Scale  Development  (l^D). 

Use  of  the  best-of-industiy  tools  and  a  highly  trained,  competent  staff  ensures  the 
highest  productiviQr  and  quality.  Profiles  of  DOD  projects  show  that,  historically,  for 
every  line  of  operational  code,  there  have  been  at  least  four  lines  of  support  software 
(Boehm,  1981).  Traditionally,  this  approach  has  increased  the  hidden  costs  of  a 
project  because  support  functions  were  either  performed  in  a  labor-intensive  manner 


Ada  Implemantation  Guide 


19 


or  additional  \nplanned  costs  were  incurred  in  tool  development  The  diversity  of 
commercial  pr  ject  support  tools  available  to  assist  in  the  generation,  documentation, 
configuration  control,  and  maintenance  of  operational  code  should  minimize  the 
need  to  develop  project-specific  support  tools. 

The  judicious  selection  of  such  tools  can  enhance  software  development 
maintenar  'e,  and  productivity;  however,  the  Program  Manager  should  ensure: 

•  The  project  support  tools  selected  are  formally  demonstrated  and  tested  before 
committing  to  their  extensive  use 

•  Software  methodologies  used  in  the  support  tools  are  consistent  with  practices 
used  in  the  supporting  software  development  or  maintenance  activity 

•  Support  tools  are  used  consistently  from  the  highest  level  of  management 
through  the  subdeveloper  level 

•  Interface  and  data  interchange  incompatibilities  among  various  tools  are 
resolved. 

The  Program  Manager  also  should  contact  the  U.S.  Air  Force  Software  Technology 
Support  Center  (STSC)  for  information  and  evaluation  data  concerning  ^plicable 
Softie  Engineering  I^vironment  (SEE)  tools,  ^pendix  A,  Section  A.1.1,  provides 
information  on  the  STSC 

Modem  systems  are  becoming  more  complex  and  frequently  test  the  limits  of  the 
tystem  development  process.  The  software  development  environment  should  be 
robust  and  flexible  to  accommodate  unforeseen  requirements.  Therefore,  managers 
of  development  activities  should  evaluate  development  tools  and  select  those  that  are 
best  for  their  applicatioiL  The  tenden^  to  procure  host  or  target  configurations  that 
minimally  support  the  requirements  of  the  software  development  process  must  be 
overcome.  It  is  important  to  provide  the  software  development  activity  with 
sufficient  processing  and  memory  capacity  to  aUow  it  to  accomplish  its  task.  Memory 
and  processing  capacity  are  relatively  inexpensive  when  the  value  of  functions 
performed  and  productivity  gains  achieved  by  software  tools  are  considered. 
Program  Managers  must  also  realize  that  an  adequate  number  of  trained 
professionals  will  be  required  to  use  and  maintain  these  tools  and  environments. 

3.U.4  life-Ctycle  Documentation 

Documenting  and  disseminating  the  standards  and  procedures  needed  to  manage  the 
development  process  are  necessary  to  ensure  ^dpline  and  consistent  in  the 
development  and  maintenance  phases  of  the  software  system  life  tdc.  Project 


Ada  Implanwntation  Guide 


21 


planning  documentation  must  identify  the  applicable  standards  and  procedures  to  be 
used  during  the  project’s  life  cyde.  Section  2  identifies  the  requirements  and 
instructions  that  describe  Ufe-cyde  management  and  documentation  standards. 

These  standards  are  meant  to  be  tailored  for  each  individual  program  and  will  vary 
from  program  to  program.  MILrHDBK-287  contains  tailoring  guidance  for 
DOD-STD-2167A,  but  no  equivalent  tooi  is  available  for  DOD-STD-7935A.  The 
Program  Manager  should  realize  that  time  spent  up  front  in  tailoring  documentation 
requirements  to  the  program’s  q>ecific  needs  can  substantially  reduce  total  life-c^de 
costs. 

3,13JS  SoltwaK  Devdopment  Process  Improvement 

The  basic  prindple  of  intern  process  management  is  that  a  development  process 
should  be  under  statistical  control.  Statistical  control  means  valid  process  in^cators 
have  been  identified  and  measured  so  that  statistical  monitoring  of  this  indicator, 
over  time,  will  accomplish  the  following: 

•  Identify  ai^  deviation  of  the  process  from  normal  operations 

•  Serve  as  a  long-term  basis  for  process  improvement 

•  Produce  desired  results  within  antidpated  limits  of  cost,  schedule,  and  quality. 

Although  statistical  control  is  well  known  in  the  manufacturing  arena,  its  use  as  a 
too)  in  the  software  development  process  is  still  in  its  infancy.  Few  process  indicators 
have  been  identified  that  reliably  contribute  to  long-term  process  improvement 

As  a  step  toward  providing  guidance  to  organizations  on  bow  to  gain  control  of 
software  development  and  maintenance  processes  and  evolve  toward  a  culture  of 
software  exceUence,  the  SEI  has  developed  the  Csqpd>ility  Maturity  Model  (CMM), 
which  is  described  in  ^rpendix  C  To  help  apply  Ae  CMM,  the  SEI  has  developed 
two  distinct  evaluation  techniques:  Software  Process  Assessment  (SPA)  and  Software 
Qq>ability  Evaluation  (SCE).  These  techniques  can  help  the  Program  Manager 
improve  in-house  software  development  and  maintenance  c^abilities  and  can 
provide  a  basis  for  selecting  qualifi^  software  developers. 

3.L3.5.1  Software  Process  Assessment 

SPA  is  a  self-diagnostic  and  improvement-initiating  activity  that  helps  software 
organizations  launch  effective  process  improvement  programs.  SEI  or  its  licensed 
vendors  provide  SPA  training,  ^pendix  A,  Section  A.1.1,  contains  information  on 
how  to  contact  the  SEI. 

Based  on  examination  of  representative  projects,  SPA  produces  a  baseline  of  the 
organization’s  process  maturity.  These  projects  may  be  old  or  new,  large  or  small. 
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and  th^  may  use  either  the  latest  languages  and  methods  or  established  languages 
and  methods.  An  effective  SPA  will  provide  software  development  organizations 
with  an  indication  of  the  current  state  of  their  software  processes,  the  high-priority 
software  process  issues  facing  the  organizations,  and  the  actions  needed  to  start 
process  in^rovement. 

Software  Capability  Evaluatton 

SCE  is  an  audit  technique  that  examines  an  organization  in  light  of  the  contract  to 
be  awarded.  Government  acquisition  organizations  use  SCE  to  help  identify  the 
capability  of  software  organizations  during  source  selection  and  to  monitor  contractor 
capability  during  contract  performance.  The  software  development  organization 
provides  candidate  projects  for  evaluation  by  the  acquisition  organization  as  an 
indicator  of  its  ability  to  perform  on  the  contract  Program  Managers  should  assess 
the  maturity  level  of  contractors  and  in-house  software  developers  before  beginning 
software  acquisition  or  development 

3.U Process  Control 

Program  Managers  must  ensure  that  reporting  mechanisms  and  procedures  are  in 
place  to  regularly  review  the  status  of  development  and  that  a  method  exists  for 
^«gs,vng  adherence  to  plans  and  controlling  rislL  The  resolution  of  critical  problems 
must  include  inputs  ft‘om  the  end  user.  Program  Managers,  and  developers. 

Program  Managers  should  institute  the  use  of  an  SEPG  as  the  primary  means  of 
process  improvement  and  control.  The  SEPG  facilitates  software  process  definition 
and  improvement  efforts.  This  should  also  be  required  of  both  Government  and 
contractor  software  development  organizations.  Program  Managers  should  have  on 
their  staffs  an  SEPG  member  who  will  help  the  Program  Manager  work  with  the 
development  organization’s  SEPG  staff  to  coordinate,  monitor,  and  facilitate  all 
contract  software  process  improvement  initiatives,  induding  SCEs,  SPAs,  metrics 
collection,  and  reporting. 

Standardization  of  the  metrics  process  is  especially  critical  to  allow  analysis  that  will 
reveal  the  cause  rather  than  the  side  effects  of  the  problem.  Formal  record  keeping 
and  accurate  traceability  of  *  op-level  requirements  down  through  coding,  testing,  and 
execution  are  vital  to  the  analysis  of  system  problems.  The  localization  and 
modularity  features  of  Ada  enhance  its  capability  to  support  traceability  through 
assignment  of  requirements  to  a  single  code  entity. 

3.U.6  Metrics 

Software  metrics  refer  to  the  measurement  of  pertinent  software  process  and  product 
parameters.  For  example,  during  certification  of  Reusable  Software  Components 
(RSCs),  use  of  a  "reusability”  metric  provides  an  indicator  of  the  level  of  effort 


Alta  Imptementation  Guide 


23 


required  to  reuse  tlw  RSC  in  a  luw  development  The  reusability  metric  becomes 
a  discriminator  that  helps  managers  choose  between  two  or  more  .  SCs  that  meet 
needed  functional  requirements.  Selecting  the  RSC  with  the  highest  reusability  score 
saves  time  and  mone^. 

Integrating  metrics  into  the  development  process  enables  an  objective  assessment  of 
development  progress,  resource  expenditure,  and  technical  product  quality.  Metrics 
must  be  identified,  qualified,  and  applied  at  the  beginning  of  the  acquisition  and 
systems  engineering  processes  and  maintained  throu^out  the  life  cycle.  Costs 
associated  with  the  collection  and  analysis  of  metrics  must  be  carefully  considered 
in  selecting  iq^propriate  software  metrics.  The  need  for  metrics  is  discussed  in 
greater  detail  in  SETs  Soft¥fare  Measurement  Concqpts  for  Acquiation  Program 
Managers  (Roxum,  1992). 

The  Program  Manager  must  ensure  that  a  software  metrics  implementation  plan  is 
in  place  before  contract  award  and  that  an  e}q)erienced  support  organization  is 
identified  to  inq>lement  the  plait  This  organization  can  initiate  assessment  activities 
during  source  selection  by  working  with  Request  for  Proposals  (RFP)>specified  and 
contractor-proposed  software  metrics.  The  implementation  plan  sho^d  provide  for 
the  foUowing: 

•  Metrics  should  address  specific  issues  of  interest  to  the  Program  Manager. 
Mbity  issues  are  common  across  programs  (e.g.,  cost  and  schedule,  personnel 
resources.  Source  Lines  of  Code  [SLOC],  defects).  A  standard  set  of  metrics 
sqn>llcable  across  major  programs  should  be  identMed  as  a  core  set  from  which 
the  project-specific  metrics  program  is  built  The  program  should  be  flexible 
and  ejqMuidable  to  address  additional  issues  that  may  be  derived  from  the 
anatysis  of  the  core  set  or  other  program  concerns.  These  additional  issues  will 
depend  on  program  size;  acquisition  strategy;  the  developer's  process;  cost, 
schedule,  and  technical  risks;  and  changes  in  Aese  characteristics  throughout 
the  life  cyde. 

•  Because  metrics  are  linked  to  a  software  process  or  product,  they  need  to  be 
collected  on  a  planned  basis  throughout  the  tystem  life  ^de. 

*  Metrics  should  be  defined  and  used  consistently  to  provide  a  critical  foundation 
for  meaningful  comparisons  (e.g.,  planned  versus  actual  costs,  differences 
between  configuration  items). 

*  Metrics  should  be  collected  automatically  when  possible  to  ensure  accura^, 
consistency,  and  timeliness.  On-line  access  to  developer  data  in  electronic 
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format  shtHild  be  provided  throughout  the  life  ^de.  Developer  data  should 
be  treated  as  proprietary  to  prevent  misuse. 

•  Metrics  should  be  analyzed  and  interpreted  to  assess  achievement  of  milestones 
and  quality  of  software  products.  Raw  metrics  can  be  misleading;  to  be  useful, 
they  must  be  interpreted  with  respect  to  the  overall  software  process. 

•  Results  of  metrics  anatysis  activities  must  be  related  to  and  used  by  decision 
makers.  The  quantitative  results  of  software  metrics  analysis  can  be  used  as 
an  indication  of  the  overall  health  of  the  program. 

To  establish  an  effective  metrics  program,  the  requirement  for  metrics  must  be 
formally  established  in  contractual  documents.  As  mentioned  above,  metrics  should 
be  defined  and  used  consistently  within  all  activities  using  that  metric.  Appendix  E 
provides  an  example  of  wording  for  use  in  a  contractual  document  to  effect  a  metrics 
program.  This  example  should  be  tailored  to  each  SEE.  Other  useful  metric 
information  can  be  foimd  in  the  SEI  report,  Software  Measures  and  the  Capability 
Maturity  Model  (Baumert,  1992)  in  whi^  13  different  measurement  categories  are 
discussed  in  det^. 

3.L3.7  Data  Management  and  Ana^^ 

In  managing  today’s  complex  system  and  software  development  efforts,  the  Program 
Manager  has  to  sort  through  a  huge  volume  of  information  and  data  from  a  variety 
of  sources  to  establish  project  status.  Frequentty,  sudi  information  and  data  (e.g., 
financial  data,  personnel  accounting  data,  problem  report  status,  softie 
development  metrics,  software  project  data)  are  stored  in  dat^ases.  To  ensure  that 
these  items  can  be  integrated  into  a  project-wide  picture  for  management  analysis, 
the  underlying  formats  must  have  interface  consistency.  Program  Managers  can 
ensure  a  measure  of  database  consistency  by  emphasizing  the  use  of  standard  data 
dictionaries  and  data  formats. 

3.L3J  Life^tyde  Maintainability 

Program  Managers  should  use  an  in-house  organization  to  monitor  the  software 
develq>ment  regardless  of  whether  or  not  the  developers  are  in-house.  The  in-house 
organization  participates  in  software  technical  reviews,  performs  milestone 
Independent  Verification  and  Validation  (IV&V)  activities,  and  participates  informal 
testi^  If  the  in-house  organization  is  the  ftiture  SSA,  the  project  can  be  guided  to 
meet  its  requirements  for  maintainability.  This  will  simplify  the  transition  of 
responsibilities  and  lower  the  long-term  costs. 
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TVaditionalty,  70%  to  80%  of  a  software  project's  ts  are  associated  with  software 
maintenance  during  PDSS.  Applications  developcu  in  Ada  using  sound  software 
engineering  are  expected  to  sign^cantly  reduce  t^  cost  as  a  result  of  the  following: 

•  Fewer  defects  per  line  of  code  because  of  Ada’s  strong  typing,  packages,  and 
exception  handling 

•  Frafrfef  understanding  of  the  code  for  both  defect  correction  and  enhancements 

•  Increased  portability  of  Ada  source  code  to  newer  hardware  if  required  later 
in  the  life  cycle 

•  Shared  cost  of  defect  maintenance  and  enhancements  for  Ada  code  reused  Ity 
other  organizations. 

For  the  PDSS  portion  of  the  life  ^de,  the  prime  developer,  another  developer,  or 
in-house  DON  personnel  may  perform  the  work.  Using  the  tystem  developer  to 
perform  the  PDSS  avoids  incompatibility  problems  between  the  development  and 
PDSS  organizations.  The  developer  knows  and  understands  the  software  better  than 
artyone  else,  hence  can  maintain  it  effectively.  The  major  disadvantage  is  that  the 
Government  can  become  locked  into  perpetual  support  performed  only  by  the  tystem 
developer  and,'  therefore,  may  be  unable  to  control  the  costt.  The  selection  of  an 
Ada  envirotunent  for  the  project  will  significantly  reduce  the  problems  traditionally 
associated  with  the  transition  from  software  development  to  PDSS  in  the  event  that 
the  tystem  developer  does  not  perform  PDSS. 

The  transition  to  PDSS  may  also  require  undue  effort  if  the  development  and  PDSS 
enviromnents  are  not  the  same  or  are  inconq>atible.  One  alternative,  whidi  is  often 
costly,  is  to  procure  an  identical  support  environment  and  install  it  at  the  PDSS  site. 
Regardless  of  the  option  chosen,  developers  must  prepare  for  the  complete  life  ^de 
before  and  during  development  In  part,  this  may  be  accomplished  Ity  requiring 
delivery  of  a  complete,  Ugh-quality  package,  including  tools  and  documentation 
sufficient  to  understand,  regenerate,  and  maintain  the  software  products,  as  well  as 
delivery  of  the  software. 

The  Program  Office  should  ensure  that  test  and  analysis  tools  acquired  for  the 
sustaining  engineering  effort  allow  life-^de  support  staff  to  work  with  the  latest 
proven  technology.  Cormnerdal  Off-The-Shelf  (CX>TS)  tools  in  the  Open  Systems 
Enviromnent  (OSE)  are  becoming  more  capable  of  supporting  Ada  applications. 
Tools  are  emerging  to  support  reverse  engineering,  to  import  Ada  source  code  into 
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higher-level  design  methods,  and  to  assist  in  .  e  conversion  of  code  from  other  High 
Order  Languages  (HOLs)  to  Ada. 

The  ISEA  and  LCSA  efforts  require  the  same  engineering  disciplines  that  are 
iqiplied  to  the  initial  development  of  the  system.  Life-^de  su(^rt  consists  of  a 
repetitive  cyde  of  development  projects.  The  common  denominator  is  that  each 
cyde  builds  on  the  results  of  the  previous  one.  In  the  past,  after  a  few  revision 
cydes,  COBOL,  FORTRAN,  JOVIAL,  and  Compiler  Monitor  System  (CMS-2) 
inq>lementations  ^ically  resulted  in  significant  degnulation  of  the  supporting  design 
documentation,  the  quality  of  embedded  comments,  and  the  integrity  of  the  tystem 
architecture. 

The  combination  of  well-defined  programming  standards  and  Ada’s  syntactic  support 
for  modularity,  abstraction,  locahzation,  and  uniformity  alleviates  this  problem  by 
providing  the  capability  to  quickly  isolate  and  correct  faults.  In  addition,  automated 
documentation  tools  can  reduce  cost  and  provide  a  vehicle  for  timely  updates.  The 
software  engineering  goals  described  in  Section  5.1.1  are  the  cornerstones  for 
ensuring  long-term,  cost-effective  maintainability  and  ease  of  revision  of  the 
supported  operational  program  software  written  in  Ada.  Although  the  use  of  Ada 
does  not  guarantee  ease  of  maintenance,  the  use  of  Ada  with  software  engineering 
is  expected  to  provide  significant  cost  reduction  during  the  PDSS. 

3.13,9  Infonnation  Sources 

Information  on  the  political,  regulatory,  commercial,  and  technological  factors  crucial 
to  successful  program  planning  and  execution  is  readily  accessible  in  a  variety  of 
forms  and  formats.  This  guide  is  a  primary  source  of  information  for  the  DON 
Program  Manager,  and  it  references  maity  of  the  most  frequently  used  sources  of 
information  on  implementation  guidance.  The  iq>pendixes  provide  additional  helpful 
sources  for  general  information,  research  tools,  program  assistance,  and  information 
technology  products  and  services. 

3.133.1  Resource  Organizations 

The  many  organizations  listed  in  Appendix  A,  Section  A.1.1,  can  be  invaluable  in 
providing  practical  infonnation  as  well  as  the  more  theoretical  information 
surrounding  the  use  of  Ada  and  software  engineering  prindples.  Both  types  of 
information  are  useful  in  program  planning. 

3.1333  Repositories 

In  addition  to  the  conventional  information  sources,  the  Program  Managers  have 
many  traditional  and  newer  electronic  repositories  of  infonnation  and  development 
assets  at  their  disposal,  including  the  following: 
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•  Legacy  software  in  relevant  i^lication  domains  that  may  provide  the 
functionality  required  and  prevent  "reinvention  of  the  vdieeL" 

•  Software  assets  (Ada  conqKments)  contained  in  DOD  and  DON  reuse  libraries 
that  can  provide  softwve-engineered  components  for  inclusion  in  new 
developments. 

•  Information  clearinghouses,  such  as  the  Ada  Joint  Program  Office’s  (AJPO’s) 
Ada  Information  Qearinghouse  ( AdalC),  which  contains  the  latest  information 
on  the  state  of  the  practice  and  project  e}q>eriences.  .^ppendix  A,  Section  A.2, 
has  information  on  AdalC 

•  Databases  containing  program  requirements  data. 

•  Benchmarks  (best  practices)  of  industiy  and  Government  that  may  be  used  as 
program  resource  requirements,  especially  in  the  early  planning  stages. 

•  Lessons  learned  from  other  organizations. 

32  ACQUISITION  PIANNING 

Section  2  provides  poli^  guidance.  Documents  used  to  ensure  that  the  software 
development  organization  selected  is  competent  in  Ada  and  has  the  requisite  systems 
and  software  engineering  experience  and  to  identify  what  and  how  the  developer  is 
to  deliver  include  the  following: 

•  Acquisition  Plan 

•  Statement  of  Work  (SOW)  (part  of  RFP) 

•  Proposal  preparation  instructions  (part  RFP) 

•  Proposal  evaluation  criteria  (part  of  RFP) 

•  Govermnent  estimate 

•  Deliverables— Contract  Data  Requirements  List  (CDRL). 

3J.1  Acquisition  Pian 

Acquisition  plarming  is  critical  to  the  success  of  any  program.  From  the  software 
perspective,  the  following  requirements  should  be  included  in  the  Acquisition  Plan: 

•  Use  of  Ada 

•  Application  of  software  engineering  principles 

•  SLOC  definition  and  estimate  as  discussed  in  Section  3.13.6 
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•  Software  reuse  as  discussed  in  Section  33.7 

•  Criteria  for  establishing  and  using  metrics  . 

•  Criteria  for  evaluating  a  contractors’s  Ada  development  csq>abilities 

•  Criteria  for  evaluating  the  contractor’s  software  engineering  process  (Software 
Developer  Maturity  Level  [SPA  or  SCE]) 

•  Criteria  for  evaluating  the  contractor’s  risk  management  c^>abilities. 

322  Statement  of  Work 

Use  of  Ada  should  be  specified  throughout  the  SOW.  The  SOW  should  dearty 
identify  those  areas  that  not  be  considered  for  an  Ada  waiver  and  those  that  may 
be  subject  to  an  Ada  waiver,  based  on  further  analysis.  In  addition,  the  elements 
subject  to  Ada  reuse  from  the  Govemment-Fumished  Equipment  (GFE)  and  other 
domains  should  be  ^dfied.  Other  issues  to  be  addressed  indude  the  following: 

•  Project  application  of  SLOC  definitions 

•  Definition  of  all  categories  of  software  and  firmware 

•  Reserve  capadties  and  software  test  acceptance  criteria 

•  Estimated  software  sizes  by  configuration  items 

•  Tailoring  of  applicable  standards  (e.g.,  DOD-STl>'2167A  and 
DOD-571>>7935A)  (See  Section  2  for  additional  policy  guidance.) 

•  Software  metric  requirements  (see  ^>pendix  E) 

•  Requirements  of  Development  Plan,  Configuration  Management  Plan,  Quality 
Assurance  Plan,  and  life-Cyde  Management  Plan 

•  Integrated  automated  documentation 

•  Use  and  delivery  vf  test  software,  support  software,  and  project-specific  data 
files. 

Appendix  E  lists  other  contract  considerations. 
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32J  Proposal  Preparation  Instructions 

Depending  on  the  scope  of  the  project,  it  is  often  beneficial  to  have  the  contractor 
submit  draft  plannii^  documents  as  part  of  the  RFP  package  and  respond  to  the 
following  issues: 

•  Commitment  to  Ada-oriented  system  and  software  engineering  processes 

•  Demonstrated  corporate  adoption  of  Ada  (e.g^  Ada  training,  Ada  eiqperience) 

•  Procedures  to  coordinate  with  the  Federal  Acquisition  Regulations  (FAR)  for 
reuse  of  a  COTS  and/or  Government  Off-The-Shelf  (GOTS)  assets 

•  Statements  regarding  rights  and  data  issue  (i.e.,  data  rights  escrows, 
documentation,  quality  and  testing,  software  liabilities,  contract  incentives)  with 
respect  to  proprietaiy  Ada  technologies 

•  Procedures  for  enforcing  the  tenets  of  Ada  and  software  engineering  in 
subcontractor  ^environments 

•  Software  development  process  control 

•  Software  metrics  program 

•  Performance  of  initial  allocation  of  function  to  configuration  items  with 
specification  of  language  and  estimated  SLOC 

•  Summary  of  successful  performance  on  previous  programs  requiring  the  use  of 
Ada. 

32A  Proposal  Evaluation  Criteria 

The  RFP  evaluation  criteria  should  include  the  following: 

•  Requirements  traceability 

•  Cost  modeling 

•  Ada  experience 

•  Plan  for  acquiring  the  required  Ada-capable  staff  needed  to  meet  contract 
requirements 

•  Ada  reuse  assets 


30 


Dopartnwnt  of  tho  Navy 


•  Ada  training  program 

•  Ada  projects  conqileted  and  size  (e.g^  SLCKO 

•  Adoption  of  Ada  for  internal  project  use 

•  Proof  of  an  Ada  software  engineering  process  and  programming  culture 

•  Software  process  maturity  level  of  repeatable  or  higher 

•  Controls  and  procedures  that  enforce  subcontractor  conq>liance  with  the 
proposed  evaluation  criteria 

•  Validation  that  software  siring,  cost,  and  schedule  are  within  Governmerit 
estimates 

•  Tools  and  environments  applications 

•  Testing  process 

•  Risk  assessment 

•  Risk  management 

•  Configuration  Management  Plan 

•  Quality  Assurance  Plan 

•  SEPG. 

3J,5  Government  Estimate 

In  developing  the  Government  estimate,  the  following  issues  should  be  considered: 

•  Experierux  of  i>evelb/wnr-<-I>evelopers  ti^o  have  not  conq>leted  two  or  three 
Ada  projects  will  be  less  productive  than  more  eiqterienced  developers. 

•  Cost  of  Code— Developing  code  to  be  reused  on  other  projects  is  more 
expensive. 

•  Inteffotion  of  ComputenAided  St^tware  Engpteering  (CASE)  into  Software 
Development  Process— To  achieve  maximum  benefit,  CASE  tools  must  be 
integrated  into  the  software  development  process. 
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•  Wora-Case  Sbemmu?— Labor*hoiir  totals  and  categoiy  allocations  should  be 
estimated  for  a  worst-case  scenario. 

•  Product  Qua%— Reuse  of  existing  Ada  code  may  lower  project  costs  and  result 
in  a  higher-quality  product 

•  0pm  Systenvs  Sumdards—\5%it  of  open  standards  (e.g.,  XWindows,  Moti^ 
Portable  Operating  System  Interface  for  Conqniter  Systems  [TOSIX], 
Government  Open  Systems  Interconimction  Profile  [CK)SIP])  can  significantty 
reduce  cost  through  improved  productivity.  A  framework  of  standards  for  an 
open  tystems  environment  is  discussed  in  Section  S3.6. 

32j6  Deliverables— Contract  Data  Requirements  List 

The  CDRL  specifies  the  deliverables  that  will  be  required  and  the  e}q)ected  quality. 
Qose  coordination  in  preparing  the  SOW  and  the  CDRLs  should  result  in  high- 
quality  software  deliverables.  The  CDRL  enables  the  Program  Manager  to  describe, 
tailor,  and  specify,  by  means  of  the  Data  Item  Descriptions  (DIDs),  the  nature, 
detail,  and  "personality”  of  the  software  deliverables.  MILrHDBK-287  provides 
guidance  for  tailoring  DIDs.  Additionalfy,  the  National  Tedmical  Information 
Service  (NTIS)  can  provide  a  PC-based  tool  ^ed  Tailor  DID.  Appendix  A,  Section 
A.13,  contains  information  on  NTIS. 

A  detailed  CDRL  does  cany  some  economic  impact  Product  quality,  however, 
reduces  the  life-qrcle  cost  of  ownership.  Bidders  should  be  instruct  to  assess  the 
CDRL  specifications  carefully,  and  evaluators  should  be  extremely  critical  of  these 
issues.  The  CDRL  must  contain  the  requirements  needed  to  ensure  good  tystems 
engineeriiig  if  the  contraa  is  expected  to  yield  a  quality  product 

The  Program  Manager  should  specify  that  contract  data  deliverables  are  to  be 
created  and  maintained  electronically  in  accordance  with  the  Computer-aided 
Acquisition  and  Logistics  Support  (CALS)  Program. 

33  SYSTEMS  ENGINEERING  AND  RISK  MANAGEMENT 
Systems  engineering  should  take  a  programmatic  view  that  recognizes  software  costs 
as  a  significant  portion  of  the  total  system  life-^de  cost  Consequently,  tystems 
engineering  must  be  considered  in  the  earfy  stages  of  a  project  During  the  System 
Definition  Phase,  the  Program  Manager  should  perform  analyses  to  identify  high-risk 
requirements  and  potential  solutions  in  the  context  of  both  hardware  and  software. 
High-risk  components  should  remain  visible  throughout  the  development  process. 
Areas  of  risk  management  for  Ada  inq}lementation  include  the  following: 
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•  Softirare  versus  hardiivie  in  a  syst^ 

•  Prototypiiig 

•  Project  context  bendunaiis 

•  Requirements  volatility  and  traceability 

•  Support  software  acquisition  impacts 

•  Coding  for  quality 

•  Ada  software  reuse 

•  Prime  developer-subdeveloper  relationsh^ 

•  Inaemental  development 

•  Integration  philosoplty 

•  Testing  philosoplty,  evaluation,  and  methodology. 

33.1  Software  Versus  Hardware  in  a  System  Context 

A  goal  of  every  Program  Manager  should  be  to  position  the  acquired  system  for  ease 
of  future  support  With  software  consuming  an  increasing  percentage  of  total 
program  budgets,  the  use  of  Ada  software  engineering  is  an  inqmrtant  factor  in 
gnahling  the  future  support  of  a  tystem.  As  for  hardware,  postponing  hardware 
selection  until  later  in  Ae  development  tyde  can  significantty  reduce  life-tyde  costs 
while  providing  greater  functiomdity.  An  excellent  case  in  point  is  the  Federal 
Aviation  Administration's  (FAA's)  Advanced  Automation  System  (AAS).  The  AAS 
contract  was  awarded  in  1988,  ai^  mudi  of  the  software  was  designed,  coded,  and 
tested  in  Ada  using  the  IBM  MVS  operating  tystem.  In  late  1991,  with  about  40% 
of  the  software  coded,  the  neuty  developed  RS/dOOO  was  selected  as  the  hardware 
for  the  AAS  controller  console.  The  code  was  easity  ported  to  the  RS/6000 
environment  By  postponing  the  decision  on  the  hardware,  FAA  will  field  the  AAS 
with  hardware  that  is  faster,  more  ciq>able,  more  reliable,  and  che^r  over  the 
expected  life  cycle. 

333  Prototyping 

Prototyping  is  recommended  as  a  method  of  risk  abatement  to  evaluate 
human-computer  interfaces  and  alternative  algorithms  and  to  confirm  requirements, 
not  as  a  means  for  rapid  deployment  Fielding  a  prototype  tystem  can  have  life-cyde 
cost  impacts  that  far  exce^  iht  theoretical  development  cost  savings.  Prototyping 
may  take  the  form  of  a  repetitive  spiral  of  alternative  solutions  that  gradualty 
narrows  the  choices  to  single  out  a  pr^erred  approadt  Still,  eadi  alternative  must 
be  planned  for  and  acoonqianied  by  disc4>lined  documentation  of  the  design 
iqiproach  and  tystem  interfa^.  Ada  directly  siq)ports  prototypng  through  the  use 
of  separately  conqnled  components. 

333  Project  Context  Benchmarics 

Development  of  bendunark  programs  that  represent  the  critical  aspects  of  a  software 
{plication  (e.g.,  Kalman  filters,  operating  tystem  overhead,  correlation  algorithms. 
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gn^hic  output)  is  recommended  to  determine  whether  available  conq>ilers  and/or 
code  generators  satisfy  projected  operational  requirements.  Benchmarks  also  help 
to  quiddy  identify  hardware  deficiencies  in  the  project  Section  4.6.13  provides 
further  discussion  of  benchmarks. 

33A  Requirements  Volatility  and  Ttaceability 

Requirements  volatility  increases  costs,  schedule,  and  undetected  error  rates.  To 
gain  the  maYimiim  productivity  from  Ada,  the  software  requirements  should  be 
baselined  at  the  Software  Requirements  Review  (SRR),  but  certainly  no  later  than 
at  the  Prehminaiy  Design  Review  (PDR).  At  PDR,  the  allocation  of  software 
functions  to  Computer  Software  Configuration  Items  (CSOs)  should  be  complete. 
At  Critical  Design  Review  (CDR),  allocations  of  these  functions  to  respective  Ada 
parVag^  specifications  should  be  complete.  Any  change  in  requirements  b^ond  this 
point  will  affect  the  cost  and  schedule.  Redesigns  required  by  requirement 
mnHifigatinns  have  the  side  effect  of  invalidating  baseline  documentation;  thus,  the 
effort  required  to  change  the  affected  documents  must  be  considered.  Prototyping, 
configuration  management,  change  control,  and  design  revision  can  reduce 
requirements  volatility.  The  configuration  management  method  should  support 
traceability  of  the  requirements  throu^  design,  coding,  and  testing  as  well  as  from 
testing  ba^  to  requirements. 

333  Support  Software  Acquisition  Impacts 

When  using  COTS  software,  the  Program  Manager  must  consider  the  stability  of  the 
product  vendor  to  ensure  the  support  environment  will  be  available  for  the  life  of  the 
tystem.  The  identification  of  data  and  data  rights  must  be  part  of  the  acquisition  of 
aity  COTS  software,  ^pendix  M  lists  several  publications  on  data  rights  that  are 
available  from  either  NTIS  or  SEI. 

33.6  Coding  for  Quality 

The  AJPO  has  suggested  the  use  of  the  Ada  Quality  and  Style  Guide  for  the 
development  of  high*quality  Ada  applications.  The  Softwsue  Productivity  Consortium 
(SPC)  wrote  this  guide  in  1989.  Since  then,  it  has  become  the  standard  guidebook 
for  Ada  programming  at  maity  organizations.  The  AJPO  has  negotiated  with  SPC 
to  use,  copy,  modify,  and  distribute  this  guide  for  aity  purpose  and  without  a  fee 
provided  it  is  distributed  with  the  copyright  notice.  The  guide  is  available  in 
hardcopy  through  the  Defense  Technical  Information  Center  (DTIC)  and  the  NTIS. 
Electronic  copies  in  both  ASCII  and  Postscript  are  available  electronically  on  the 
ajpo  host  and  on  the  AdalC  Bulletin  Board,  .^xpendix  A,  Section  A.13,  provides 
information  on  DTIC  and  NTIS. 
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3J.7  Ada  Software  Reuse 

Software  reuse  is  important  to  DOD  and  the  Ada  community  because  reuse  promises 
a  hi^er*quality  product  with  significant  cost  savings  across  the  software  life  qrcle. 
Althou^  software  reuse  was  not  specifically  identified  as  a  design  criterion  for  the 
Ada  language,  the  concept  of  reuse  is  strongly  implied  in  the  design  criteria. 

Domain  analysis  is  a  method  of  identifying  the  commonalties  and  variations  of 
evicting  ^tems  within  the  .me  application  area  to  determine  reuse  candidates. 
Domain  analysis  should  be  ]  erformed  in  the  Requirements  Analysis  Phase  to  gain 
a  better  imHarstanding  of  existing  systems  in  terms  of  common  fimctionality  and  to 
identify  from  existing  tystems  that  can  be  reused  in  the  current 

development  A  side  benefit  of  domain  analysis  is  stabilizing  the  requirements 
through  the  early  discovery  of  missing  requirements. 

Use  of  Ada  as  the  implementation  language  does  not  Ity  itself;  ensure  reusability. 
Among  other  things,  a  library  of  reusable  programs  and  established  Ada 
programming  standards,  polides,  and  procedures  are  necessary,  libraries  of  reusable 
Ada  programs  have  great  promise  for  reducing  future  softw^e  development  costs. 
The  Program  Manager  must  be  aware  of  issues  that  will  make  maintenance  of  the 
library  attractive  to  the  development  contractor  (e.g.,  data  rights).  Section  533 
provides  additional  details  on  software  reusability,  and  Appendix  A,  Section  A.13, 
provides  a  list  of  software  repositories. 

33.8  Prime  Developer-Snbdeveloper  Relationships 

In  selecting  subdevelopers,  the  prime  developer  should  aqrply  the  Ada  technology 
acquisition  criteria  discussed  throughout  Section  32.  The  prime  developer  must  be 
as  analytical  in  selecting  its  subdevelopers  as  the  Govenunent  is  in  selecting  the 
prime  developer.  For  its  part,  the  Government  should  consider  the  subdeveloper’s 
capabilities  and  commitment  to  Ada  in  the  same  light  as  those  of  the  prime 
developer.  The  relationship  between  the  prime  developer  and  its  subdeveloper 
should  not  be  taken  for  granted.  The  RFP  should  specify  that  the 
developer-subdeveloper  relationship  be  explicitly  described  in  ^e  proposal  and 
should  include  proposal  evaluation  criteria  that  address  this  relationsUp. 

333  Incremental  Development 

Shrinking  budgets  as  well  as  poorly  defined  and  shifting  requirements  have  put  maity 
programs  at  risk.  To  reduce  risk,  one  strategy  employed  Ity  Program  Managers  is  to 
address  software  developments  in  increments.  T^  facilitates  the  reevaluation  and 
optimization  of  requirements  when  moving  from  one  incremental  phase  to  the  next 
Ibe  software  engineering  features  of  Ada  (e.g.,  packages,  generics,  information 
hiding,  and  abstraction)  support  this  risk-reducing  approach. 
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33.10  Intention  Philosoplqr 

The  size  and  complexity  of  DON  systems  are  inaeasing.  As  a  result,  systems 
integration  is  growing  in  prt^rtion  and  inqxntanoe.  Both  the  tactical  and 
worlds  are  developing  highly  con^lex,  multifunctional  systems,  and  the 
distinctions  that  once  existed  between  the  tystems  used  in  these  two  worlds  are 
becoming  blurred.  A  classic  exanq>le  is  the  critical  time  requirements  of  modem 
logistics  tystems  to  support  the  n^id  deployment  and  multimission  fimctionality  of 
tody’s  naval  forces. 

Ada  use  increases  in  importance  in  light  of  the  diversity  of  hardware  required  for  the 
wide  variety  of  these  operational  environments.  Ada  can  be  iqq>lied  over  most  of 
these  environments  for  mission  performance  and  problem  solving.  With  the 
appropriate  systems  engineering  practices  and  policies,  Ada  could  contribute 
significantly  to  easing  the  multivendor,  multimission  integration  problems 
encountered  in  today's  systems. 

33.11  Testing  Philosophy,  Evaluation,  and  Methodology 

Because  of  the  increasing  conq)lexity  and  size  of  emerging  systems,  a  testing 
philosophy  must  be  considered  and  built  in  at  the  concept  formulation  phase  of  a 
project  All  requirements,  developed  and  derived,  must  be  evaluated  not  only  for 
their  iq)plication  to  the  problem  statement  or  mission,  but  also  for  testability. 
Large-scale,  heterogeneous,  distributed  systems  must  be  thoroughly  tested  as  modules 
and  subsystems  as  the  system  is  built  and  comprehensively  tested  as  an  integrated 
tystem.  The  appropriate  use  of  Ada  conponents  should  sipport  the  testing 
philosophy  by  providing  a  capability  to  confirm  the  implementation  of  requirements 
and  evaluate  them  for  coirpleteness.  Because  the  components  provide  a  defined 
external  interface,  integration  and  testing  problems  are  minimized.  Test  planning 
must  start  in  the  Requirements  Definition  Phase  (e.g.,  requirements  vaiUdation, 
requirements  realism,  and  transitioning  of  requirements  to  function).  Contracts  must 
ensure  and  enforce  requirements  for  unit  testing  of  the  individual  functional 
capabilities;  full-scale  integration  testing;  verification,  validation,  and  certification 
testing;  and  life-cycle  support  testing. 

Ada  supports  the  identification  of  errors  during  the  early  Design  and  Coding  Phases 
through  compilable  program  specifications,  strong  typing,  and  constraint  dieddng. 
Constraint  checking  takes  place  staticalty  during  compilation  and  d^namicalty  during 
run  time  where  an  exception  is  raised  can  be  easity  processed.  This  constraint 
diedong  can  be  disabled  to  improve  system  perfomumce  after  all  testing  has  been 
completed.  These  features  help  to  uncover  errors  earlier  in  the  development  process. 
In  the  end,  the  cost  impact  of  error  repair  during  integration  testing  demonstrates 
that  this  phase  should  focus  on  integration,  not  discovery  of  unit  code  errors,  bad 
des^  or  ambiguous  requirements. 
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In  the  past,  the  error  conection  process  often  applied  patches  to  the  stnirce  code 
because  complete  system  generation  was  time  consuming.  Patches  are  unnecessary 
udien  the  ^tem  is  properly  designed  1^  using  Ada  packages.  Errors  corrected  within 
a  package  body  require  onfy  the  reconq>iiation  of  the  package  bocfy  and  relinking, 
wUch  significant^  reduces  the  time  for  a  complete  system  regeneration. 

Testing  methodologies  include  the  use  of  designed-in  test  structures  and  the 
application  of  tools  for  modeling  simulation,  design,  development,  and  (^rational 
assessment  of  systems  in  both  the  hardware  and  software  arenas  throughout  the 
development  process.  When  used  as  part  of  a  weU-defined  ^tems  engineering 
approach,  Ada  supports  an  incremental  build  and  test  approach. 

3.4  HIGHLIGHTS 

The  preceding  sections  provide  general  guidance  for  Program  Managers  in 
incorporating  Ada  and  software  engineering  into  a  program's  life  cycle.  This 
subsection  highlights  the  critical  points  in  each  phase. 

Guidance  for  the  Program  Planning  Phase,  for  example,  emphasizes  the  need  for 
integration,  up-firont  preparation  of  procedures,  and  careful  tool  analysis  and 
selection.  This  guidance  may  be  summarized  as  follows; 

•  Ensure  the  program  organizational  structure(s)  integrates  the  activities  of  the 
Program  Office,  the  operational  users,  and  developers;  embodies  clearly 
de^ed  lines  of  authority;  and  supports  promotion  of  Ada  use  and  enforcement 
of  Ada  policy  and  standards. 

•  Ensure  that  Ada  expertise  is  available  within  the  management  and  support 
organizations. 

•  Use  parametric  modeling  and  cost-estimating  tools.  Ada  sizing  inputs  to 
estimation  models  should  be  based  on  Ada  statements  or  terminal  semicolons 
rather  than  on  lines  of  code. 

•  Develop  a  training  strategy: 

-  Address  software  engineering  and  Ada  training. 

-  Ensure  appropriate  training  at  all  levels  of  the  organization. 

-  Ensure  the  training  is  just  in  time. 

-  Use  on-site  mentors. 

•  Identify,  document,  and  disseminate  standards  and  procedures  needed  to 
manage  the  software  reuse  and  development  process. 
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•  Identify  metrics  to  be  applied  at  the  beginning  of  the  systems  engineering  and 
software  inq)lementation  processes. 

•  Take  advantage  of  the  information  sources  available  on  political,  regulatoiy, 
gnmmgrrial,  and  technology  and  lessons  learned  ftt>m  other  projects. 

Guidance  for  the  Acquisition  Planning  Phase  relates  primarify  to  the  requirements 
of  the  RFP.  Highlights  of  this  guidance  are  as  follows; 

•  Develop  a  strong  acquisition  plan  and  other  documents  needed  to  ensure 
selection  of  a  conq>etent  Ada  developer. 

•  Ensure  the  RFP  SOW  provides  specifications  on  Ada  use  and/or  reuse,  defines 
all  of  the  applicable  software  and  firmware  categories,  specifies  conformance 
to  applicable  standards,  and  states  the  software  metrics  requirements. 

•  In  the  RFP  evaluation  criteria,  emphasize  contractor  e)q>erience,  training,  and 
competence  in  Ada  use  and  reuse  as  well  as  requirements  traceability,  cost 
modeling,  and  subcontractor  compliance  with  the  evaluation  criteria. 

For  the  Systems  Engineering  and  Risk  Management  Phase,  the  guidance  provided 
stresses  the  importance  of  considering  software-related  issues  from  the  outset  and 
identifying  high-risk  hardware  and  software  components.  Specific  guidance  in  this 
area  includes  the  following: 

•  Define  software  requirements  in  parallel  with  hardware  requirements. 

•  Use  protofyping  and  benchmarks  to  mitigate  risk. 

•  Freeze  requirements  no  later  than  the  PDR. 

•  Identify  opportunities  for  and  consider  reuse  of  Ada  source  code. 

•  Ensure  the  prime  developer  applies  the  same  Ada  technology  acquisition 
criteria  in  selecting  subdevelopers  as  the  Government  used  in  the  selection  of 

prime  developer. 

•  Implement  processes  that  identify  errors  earfy  in  the  D^elopment  Phase  to 
avoid  costly  repair  during  the  Integration  and  Test  Phase. 

•  Ensure  tnat  the  cycle  of  inaemental  builds,  test,  and  repair  are  under 
configuration  management 
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This  section  discusses  the  envinnuDimts  used  to  aipport  the  develt^ment  and 
maintenance  of  Ada  ^tplicalion  software. 

4.1  PROJECT  SUPPORT  ENVIRONMENT 

The  term  "environment*  evolved  from  ea^  work  on  the  UNIX  operating  i^stem  and 
original^  referred  to  setting  certain  parameters  and  diaracteristics  of  t^  qpentwg 
system  to  create  a  programming  or  emitting  environment  suitable  for  the  user. 
From  the  start,  the  term  inqilied  select^  or  tailoring  the  environment  to  meet 
q)ecific  user  needs.  Gradual^,  the  term  became  more  general,  referring  to 
^gramming  or  Project  Support  Environments  (PSEs),  thus  reflecting  the  idea  that 
the  environment  was  desig^  and  constructed  to  support  a  particular  of 
i^Iicadons.  The  phrase  "Software  Engineerii^  Environment"  (SEE)  was  then  used 
to  refer  to  a  set  of  oonqniter  tools  to  si^>port  the  activities  of  software  engineering. 

A  SEE  that  supports  software  development  is  a  computer-based  set  of  integrated 
methods,  tools,  and  procedures  to  develq>  software  that  meets  mission  needs.  This 
definition  inherently  means  that  a  ^E  must  provide  the  functions  of  both  a 
programming  development  ^stem  and  a  management  information  ^tem  to  monitor 
and  control  Ae  development  The  term  "Ada  environment*  means  that  the  scope  of 
the  SEE  is  focused  on  siq^rting  the  development  of  software  written  in  the  Ada 
programming  language  and  the  associated  software  engineering  methods  and 
procedures. 

Current^,  the  accepted  practice  is  to  execute  the  SEE  on  host  conqraters  to  develop 
project  software  during  the  Requirements,  Design,  Coding,  Integration,  and  Testing 
Phases.  Normally,  system  integration  and  testing  are  performed  in  system  test 
facilities  with  support  from  the  SEE.  The  SEE  is  then  used  for  the  remainder  of  the 
system  life  cyde. 

Other  terms  for  SEEs  that  appear  in  the  general  literature  indude  Software 
Development  Environment  (SDE),  Integrated  Software  Engineering  Environment 
(IS^),  PSE,  Ada  Programming  Support  Environment  (Ada  PSE),  and  Integrated 
Project  Support  Environment  (IPSE).  The  term  PSE,  whidi  sq)pears  in  the 
remainder  of  this  section,  is  used  interdiangeabfy  to  mean  project  and  programming 
support  environments. 


TOOLS 

A  variety  of  tools  is  used  in  PSEs.  These  tools  may  vary  significantly  from  one  PSE 
to  another.  A  few  tools  are  used  in  almost  every  i^lication  although  several  other 
tools  exist  that  are  desirable  and  can  improve  productivity  across  the  software  life 
tyde. 

4J.1  Minimum  Tool  Set 

The  miniitiiiTn  tool  set  consists  primarily  of  those  tools  associated  with  the  coding 
phase  of  development,  including  the  following: 

•  Editor  is  used  to  aeate  or  modify  source  code  and  to  view  or  modify  files 
produced  by  other  tools. 

•  Compiler  translates  a  High  Order  Language  (HOL)  source  program  into  its 
relocatable  code  equivalent 

•  Assembler  translates  an  Assembly  source  program  into  relocatable  code. 

•  Linker  creates  a  load  module  fi’om  one  or  more  independently  translated 
modules  by  resolving  the  cross-references  among  the  modules.  Some  vendors 
separate  part  of  this  functionality  and  provide  it  in  a  separate  binder  tool. 

•  Relocating  Loader  executes  on  the  host  computer  and  translates  the  relative 
addresses  into  the  absolute  addresses  and  produces  an  execution  module. 

•  Run-Time  Environment  (RTE)  provides  a  variety  of  operating-system-like 
services  for  application  programs  (also  known  as  run-time  executive). 

•  Profiler  provides  a  mechanism  to  monitor  the  ^namic  aspects  of  an  application 
(e.g.,  scheduling,  Central  Processing  Unit  [CPU]  utilization,  Input/Ou^ut  [I/O] 
channel  loading). 

•  Simulator/Emulator  simulates  or  emulates  the  target  computer  but  executes  on 
the  host  computer  and  greatly  increases  testing  productivity. 

•  In-circuit  Emulator  emulates,  tests,  and  traces  the  prototype  tystem  operation 
when  connected  to  the  prototype  tystem  through  the  microprocessor  socket 

•  Symbolic  Debugger  allows  a  programmer  to  test  a  module  tty  controlling  the 
program  execution  on  a  target  computer  emulator  or  the  target  computer  itself 
by  using  source  program  tymbols  or  names. 
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•  Fretty  Printer  automatically  aiqplies  standard  rules  for  formatting  program 
source  code. 

•  Host-to-Torga  Ejqtorter  provides  a  tool  to  transmit  the  execution  module  from 
the  host  to  the  target  v^en  iht  target  machine  is  different  from  the  host 
madiine. 

A  more  coiiq>rehensive  set  would  indude  tools  covering  the  following  categories: 
^tax<directed  program  editing,  confi^iration  management,  ^stem  modeling,  Ada 
program  design,  software  specification  and  design,  software  tedmical  documentation 
aids  that  facilitate  IX)D>STD-2167A  document  production,  software  quality  and 
performance  analysis,  and  project  management  Such  tools  are  often  referred  to  as 
Computer-Aided  Software  En^eering  (CASE)  tools,  ^pendix  F  provides  a  more 
detailed  discussion  of  these  tools. 

422  Commerdal  Ada  Devdopment  Tools 

Ada  has  matured  significantly  over  the  last  few  years.  Today,  many  vendors  supply 
several  hundred  validated  Ada  compilers  for  a  number  of  commercial  configurations. 
The  Ada  Joint  Program  OfGce  (ATPO)  updates  the  list  of  validated  Ada  compilers 
monthfy  and  makes  the  list  available  on  the  AJPO  host  computer  on  the  Defense 
Data  Network  (DDN).  To  obtain  the  list,  contact  the  Ada  Information 
Qearinghouse  (AdalC).  Appendix  A,  Section  A2,  provides  information  on  AdalC 
and  the  material  it  supplies. 

In  addition,  hundreds  of  commercial^  available  tools  exist  that  are  backed  their 
vendors  to  support  the  development  of  Ada  iq>plications  across  the  software  life 
cycle.  Tools  are  available  to  support  both  hierarchical  and  object-oriented  design. 
Other  tools  are  available  that  produce  and  use  Boodi  diagramyj  Buhr  diagrams, 
Demarco  data  flows,  entity  relationships,  flowcharts,  functional  flow  diagrams,  state 
transition  diagrams,  and  structure  charts.  Some  of  these  tools  provide  automatic 
code  generation  from  the  design  diagrams. 

In  addition,  tools  exist  to  support  source  code  translation  to  Ada  from  Assembly,  C, 
COBOL,  Program  Design  Language  (PDL),  JOVIAL,  USP,  and  Pascal  Even  Ada 
artificial  intelligence  tools  are  commercii^  available  to  support  the  building  of 
e)q)ert  ^tems,  knowledge-based  ^tems,  natural  langm^g^,  ^tems,  and  neural 
networks. 

The  AJPO  maintains  an  on-line  Ada  Products  and  Tools  Database  that  can  be  used 
to  find  out  more  about  these  tools.  In  addition,  the  Software  Technology  Support 
Center  (STSC)  maintains  information  in  the  form  of  a  database  and  reports  for  tools 
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to  nq^rt  a  SEE.  ^>peiidix  A,  Section  A.1,  provides  more  information  on  both 
AJPOandSTSC 

43  MISSION<<3UTICAL  COMPUIER  RESOURCES  ENVIRONMENT 
Department  of  Navy  (DON)  software  i^lications  for  mission  critical  ^tems  run  on 
a  wide  variety  of  target  computer  systems  including  commercial^  based 
microprocessors  and  computers  and  military-unique  computers  such  as  the  Navy 
Standard  Embedded  Computer  Resources  (SECR).  Often  the  program  support 
environment  tools  selected  for  such  qrplications  run  on  a  host  computer  ^tem  that 
is  from  the  target  computer  ^tem.  The  host  system  provides  the  resources 

for  development,  simtdation,  documentation,  and  test  of  software  q>plications  to  be 
compiled  for  the  target 

Navy  SECR  computers  include  the  AN/UYK-43(V),  AN/UYK-44(V),  and  the 
AN/AYK-14(V).  The  Ada  Language  System/Navy  (ALS/N)  serves  as  the  validated 
Ada  compiler,  the  run-time  software,  and  the  PSE  for  the  SECR  computers.  Section 
43.4  provides  further  discussion  of  ALS/N.  For  Navy  commodity-managed 
computers,  such  as  the  Desktop  Tactical  Computer  (DTC-2)  and  the  Tactical 
Advanced  Computer  (TAC-3),  validated  Ada  compilers  may  be  selected  through  the 
DTC-2  and  TAC-3  ordering  contracts  for  the  commercial  derivatives  of  the  DTC-2 
(Sun  SPARC  Workstation)  and  TAC-3  (Hewlett-Packard  [HP]  Workstation  9000) 
Because  the  DTC-3  and  TAC-3  are  based  on  widely  used  commercial  workstations, 
a  wide  variety  of  commercial  PSEs  are  available  to  support  Ada  software 
developments. 

Matty  DON  mission-critical  Ada  ^plications  have  been  developed  and  fielded 
successfully  by  using  commercial  processors  and/or  computers,  validated  commercial 
compilers,  and  commercial  PSEs.  Use  of  commercial  computer  resources,  compilers, 
and  PSEs  has  greatly  fodlitated  and  accelerated  Ada  inqtlementation  within  the 
DON. 


4.4  AUTOMATED  INFORMATION  SYSTEMS  ENVIRONMENT 
The  Congressional  mandate  to  use  Ada  throughout  the  DON  will  result  in  having 
many  Automated  Information  System  (AIS)  applications  programmed  entirely  in 
Ada.  The  AIS  community  uses  a  wide  range  of  commercial  hardware  and  softu^e. 
Therefore,  the  DON  strategy  for  establishing  the  Ada  environment  for  AIS  will 
incorporate  the  use  of  Ada  into  an  Open  Systems  Environment  (OSE)  that  will 
provide  the  capability  to  integrate  and  transport  iq)plication  software  across  multiple 
conqniter  tystems.  Current  policy  requires  that,  once  the  Integrated  Conq>uter-Aided 
Sofh^e  Engineering  (I-CASE)  contract  has  been  awarded,  all  tools  for  AIS 
environments  should  be  selected  from  this  contract 
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4J  PROJECT  SUPPORT  ENVIRONMENT  OPTIONS 
PSEs  are  critical  to  the  successful  development  and  maintenance  of  DON  computer 
systems.  Ada  PSEs  include  commercial  Ada  environments,  ALS/N,  AdaSAGE,  and 
Ada-Based  Environment  for  Test  (ABET). 

4.5.1  Commercial  Ada  Environments 

The  commercial  Ada  PSEs  based  on  validated  Ada  compilers  are  steadily  increasing 
in  number  and  becoming  more  mature.  Commercial  Ada  PSEs  ^icalfy  contain  a 
set  of  ^tem  tools  that  provides  capability  for  data  management,  resource 
management,  and  scheduli^.  Additionally,  they  provide  the  target  RTE  with 
loaders,  debuggers,  and  the  like.  Although  die  completeness  and  quality  of  these 
Ada  PSEs  vary,  several  highly  capable  Ada  PSEs  have  evolved. 

These  commercial  environments  have  been  exceptionally  powerful  for  the 
development  of  Ada  software  on  both  h(»t  and  target  environments.  A  wide  range 
of  CASE  took,  which  are  discussed  in  Appendix  F,  support  these  commercial  Ada 
environments.  The  AdalC  and  STSC,  which  are  descried  in  Appendix  A,  Section 
A.1.1,  also  can  provide  information  on  these  environments. 

4£2  AdaSAGE 

AdaSAGE  is  an  applications  development  set  of  utilities  designed  to  facilitate  rapid 
construction  of  systems  in  Ada.  Applications  may  vary  from  small  to  large 
multiprogramming  systems  that  use  spe^  capabilities.  These  capabilities  include 
Structured  Query  Language  (SQL)-compliant  database  storage  and  retrieval, 
graphics,  communications,  formatted  windows,  on-line  help,  sorting,  editing,  and 
more.  AdaSAGE  operates  on  MS-DOS  and  UNIX  platforms,  and  AdaSAGE 
applications  can  be  run  in  the  stand-alone  mode  or  in  a  multiuser  environment.  A 
developer  using  the  Ada  language  and  the  AdaSAGE  development  tystem  can  design 
a  product  that  is  tailored  to  a  specific  requirement  and  offers  outstanding 
performance  and  flexibility. 

AdaSAGE  is  an  effective  environment  for  developing  software  applications  primarily 
for  the  AIS  and  some  scientific  and  engineering  domains.  The  environment  allows 
the  user  to  build  applications  through  an  interactive  screen  editor.  Here,  the 
af^lications  developer  is  presented  with  options  that  are  based  on  reusable  modules 
in  the  AdaSAGE  program  libraiy.  After  all  options  have  been  selected  for  an 
application,  the  AdaSAGE  environment  builds  the  Ada  source  code,  which  then  can 
be  compiled  to  create  the  application.  Developers  with  limited  knowledge  of  Ada 
or  of  software  engineering  can  develop  simple  applications.  Development  of  larger 
applications  may  require  programmers  skilled  in  Ada  and  software  engineering. 
Functionality  and  potential  benefits  of  AdaSAGE  include  rapid  prototyping, 
programmer  reusability,  and  efficiency. 
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All  four  Services  have  reported  significant  success  in  developing  applications  with 
AdaSAGE.  The  Depa^ent  of  Energy  and  private  industiy  also  are  using 
AdaSAGa 

Additional  enhancements  to  this  environment  are  under  way,  funded  several 
sources  including  the  AJPO’s  Ada  Technology  Insertion  Program  (ATIP). 

4,53  Ada>Based  Environment  for  Testing 

ABET  is  a  set  of  software  interface  standards  for  Automated  Test  Equipment  (ATE) 
environments  used  to  assist  in  the  development  and  execution  of  automatic  tests 
udng  the  Ada  programming  language.  These  software  interface  standards  are 
defined  to  support  hardware  or  software  component  portability,  reusability, 
exchangeability,  and  interoperability  and  to  serve  as  targets  for  test-related  software 
development  tools. 

Each  ABET  interface  is  defined  in  one  of  the  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  ABET  component  standards  (IEEE  Std  1226j().  The  ABET 
component  standards  define  the  Ada  padcages  and  data  structures  that  are  used  to 
give  a  comparable  capability  to  the  associated  reference  documents.  They  also 
define  mappings  between  the  reference  documents  and  the  Ada  packages  and  data 
structures. 

The  ABET  interface  standards  can  be  grouped  in  an  ABET  layer  model  The  layers 
of  this  model  are  as  follows: 

•  The  Product  Description  Layer  supports  the  link  from  design-oriented  product 
description  information  to  test-oriented  product  information.  The  design  data 
may  include  descriptions  of  the  Units  Under  Test  (UUTs)  physical  and  circuit 
design  and  its  externally  measurable  characteristics  and  responses  and  the 
stimuli  needed  to  elicit  them.  Standardization  of  these  interfaces  supports 
analysis  of  test  and  maintenance  issues  during  the  Product  Design  Phase  as 
well  as  development  of  automated  tools  to  generate  the  requirements  or 
procedures  directly  from  UUT  product  descriptions. 

•  The  Test  Strat^/Requirements  Layer  supports  the  specification  of  UUT  test 
requirements,  test  strategies,  automatic  test  generation,  diagnostic  models,  and 
collection  and  retrieval  of  maintenance  data. 

•  The  Test  Procedure  Lt^er  supports  full  signal-oriented  vocabulary  and  semantics 
and  the  UUT-oriented  virtual  resource  model  of  ATLAS  and  includes  the 
capability  to  relate  UUT  test  requirements  to  virtual  test  resources  that  are 
independent  of  aity  particular  ATE. 
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*  Hie  ATE  System  Layer  specifies  the  mapping  of  virtual  resources  to  real 
resources,  signal  routing,  and  access  to  non-UUT  signal<oriented  test  ftinctinns 
and  maintaias  and  reports  on  ATE  status. 

•  The  Instrumatt  Control  Layer  standardizes  access  to  command  and 
communication  protocols  used  by  real  test  resources.  This  will  allow  test 
resources  with  common  functionality  made  by  ai^  manu&cturer  to  be  used  to 
perform  identical  functions. 

4.5.4  Ada  Language  System/fiavy 

ALS/N  is  a  software  development  and  RTE  that  is  being  developed  for  the  current 
generation  of  DON  standard  computers:  the  AN/UYK-43(V),  AN/ljYK-44(V),  and 
AN/AYK-14(V).  The  ALS/N  development  is  sdieduled  to  be  completed  the  end 
of  Fiscal  Year  1993.  Present  plans  call  for  two  additional  years  of  maintenance;  after 
that  period,  user  projects  will  be  required  to  provide  support  for  maintgnanfy 

ALS/N,  which  is  hosted  on  the  VAX  series  of  computers  using  the  VMS  operating 
^tem,  has  been  validated  as  Ada/L  for  the  AN/UYK-43(V)  and  as  Ada/M  for  the 
AN/UYK-44(V)  and  AN/AYK-14(V). 

ALS/N  consists  of  two  functional  parts:  the  Minimal  Ada  Programming  Siqiport 
Environment  (MAPSE)  and  the  RTE  The  MAPSE  consists  of  the  compiler  and 
other  associated  compile-time  tools  that  run  on  a  host  computer  and  produce 
software  products  for  a  target  computer. 

The  RTE  software  provides  services  needed  by  the  executable  application  program 
and  supports  execution  of  those  programs  so  as  to  meet  the  requirements  of 
performance,  reliability,  and  fault-tolerance  on  the  target  computer.  The  RTE 
provides  the  basic  and  extensible  software  facilities  required  to  support  Ada  use  in 
the  mission,  support,  systems,  test  and  maintenance,  and  trainer  software  categories. 
RTE  tools  include  the  run-time  operating  tystem,  executive,  librarian,  loader, 
run-time  sqiplication  support,  run-time  debugger,  embedded  target  debugger,  and 
run-time  perl.:rinance  measurement  aids.  The  ALS/N  RTE  provides  run-time 
support  -or  the  AN/UYK-43(V),  AN/UYK-44(V),  and  AN/AYK-14(V)  embedded 
target  computers  only. 

4.6  SELECnON  OF  THE  PROJECT  SUPPORT  ENVIRONMENT 
The  subsections  below  provide  PSE-related  information  for  compiler  selection, 
av^bility  of  KE  standards,  upgrades  to  newer  versions  of  tools  within  a  PSE, 
mixing  Ada  with  other  languages,  and  mixing  executable  Ada  from  different 
compilers. 
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4.6.1  Compiler  Selection 

A  compiler  is  a  software  tool  or  product  that  receives  as  input  the  HOL  or 
source-language  statements  develop  designers  and/or  programmen  and 
translates  or  compiles  these  statements  into  madiine-readable,  executable  code. 
Vendors  typically  provide  a  set  of  tools  in  addition  to  the  con^iler  and  call  the 
collection  a  "compilation  system."  A  typical  compilation  system  includes  only  a 
compiler,  linker,  loader,  library,  and  fundamental  program  execution  (run-time) 
structure.  Other  vendors  package  additional  tools  (e.g.,  interfaces  and  support  for 
progranuner  productivity,  testing  and  configuration  management  tools,  and  structures) 
into  the  compilation  system.  Consequently,  these  packages  are  almost  complete 
software  development  enviromnents. 

Each  manager  must  select  the  best  compiler  for  particular  project  needs.  The 
compiler  selection  process  should  begin  with  a  plan  that  establishes  the  project 
requirements,  budget,  persoimel,  and  timetable.  To  reduce  risk,  the  selection  process 
must  identify  key  criteria  and  test  the  candidate  compilation  tystems  against  the 
criteria.  The  criteria  for  selecting  a  compiler  should  be  based  on  the  nature  of  the 
project;  for  example,  concern  about  execution  time  would  not  be  as  applicable  in  a 
batch-type  application  as  in  a  tactical  program.  Based  on  these  criteria,  bendunarks, 
checklists,  and  interviews  should  be  used  as  needed  to  assess  different  compilers  for 
spedfic  project  requirements,  and  a  limited  number  of  candidate  compilers  should 
be  selected  for  detailed  evaluation.  Several  types  of  benchmarks  and  test  suites  can 
be  used  to  evaluate  compiler  implementation.  No  single  test  suite  or  checklist 
suffices  for  every  project  (Weiderman,  1989). 

Evaluation  of  Ada  compilation  systems  for  a  particular  user  application  will  decrease 
project  risk  and  reduce  total  cost  and  schedule  overruns.  Evaluation  and  selection 
apply  to  the  entire  software  development  package,  not  just  the  conpiler.  Evaluating 
and  selecting  an  Ada  compilation  system  for  a  project  are  complex  and  costly 
processes.  The  means  avsiUable  to  support  them,  as  discussed  ^low,  are  very 
important,  but  it  will  always  be  necessary  to  supplement  them  with  project-specific 
criteria. 

4.6.1.1  Validation 

All  Ada  compilers  must  pass  formal  validation  to  ensure  conformance  to  American 
National  Standards  Institute  (ANSI)/Military  Standard  (MI1^STD)-181SA.  DOD 
Directive  5000.1  and  DOD  bstruction  5000.2  require  that  all  DOD  initiatives  use 
validated  compilers.  A  list  of  validated  compilers  can  be  obtained  from  the  AdalC 
The  formal  ^i^dation  consists  of  iq>proximately  4,000  tests  known  as  the  Ada 
Compiler  Validation  Capability  (ACVC).  A  formal  validation  ensures  that  an  Ada 
compiler  correctly  implements  the  Ada  language  syntax  as  defined  the  standard. 
A  validation  does  not,  however,  assess  performance  or  machine-dependent  language 
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features.  Section  4.6.13  provides  a  discussion  of  benchmarks.  Ada  coinpiier 
developers  who  want  to  validate  their  products  may  obtain  information  on  the 
current  version  of  the  ACVC  test  suite  b^m  the  AJPO  or  the  National  Institute  of 
Standards  and  Technology  (NIST). 

Project  Managers  must  select  a  validated  Ada  compiler  for  their  software 
development  projects.  Validations  are  issued  for  a  tested  host  and  target 
combination  with  an  expiration  date.  It  is  important  to  verify  that  selected  compilers 
have  been  validated  against  the  most  recent  version  of  the  test  suite.  The  timing  of 
compiler  procurement  should  correspond  with  the  start  of  the  project  A  validated 
compiler  used  at  project  start  is  considered  validated  for  the  entire  life  ^cle  of  the 
designated  project,  even  if  the  expiration  date  has  passed. 

4.6.13  Evaluation 

The  goal  of  formal  evaluation  is  to  provide  vendors,  procurers,  and  users  of  Ada 
implementations  with  comparable  compiler  performance  data.  These  data  enable 
vendors  to: 

•  Improve  compiler  implementation  performance 

•  Allow  procurers  to  select  implementations  and  configurations  that  best  meet 
their  project  needs 

•  Help  users  identify  the  best  language  features  to  use  for  that  particular 
application 

•  Help  users  identify  the  language  features  to  avoid  for  that  particular 
application. 

Two  ^tems  are  available  for  Ada  compiler  evaluations:  the  Ada  Compiler 
Evaluation  Capability  (ACEC)  and  the  Ada  Evaluation  System  (AES).  Work  is 
under  way  to  merge  the  ACEC  and  AES  into  the  Ada  Compiler  Evaluation  System 
(ACES).  The  merged  product  is  expected  to  be  available  in  niid>1993. 

4.6.13.1  Ada  Compiler  Evaluation  Capabilify 

In  1983,  AJPO  formed  the  Evaluation  and  Validation  Team  to  examine  PSE  and  tool 
evaluation  and  validation  issues  and  provide  a  capability  to  assess  Ada  PSEs  to 
determine  their  conformance  to  applicable  standards.  One  result  was  the  ACEC. 
The  current  AQBC  is  available  from  the  Data  and  Analysis  Center  for  Software 
(DACS);  information  on  DACS  is  available  in  Appendix  A,  Section  A.13. 
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The  ACEC  strengths  indude  the  depth  of  coverage  for  language  features, 
documentation,  documented  structure,  ^e  size  measurements,  timing  tedmiques 
with  a  statistical  model,  and  aoss<system  analysis  software.  The  shortcomings  are 
lack  of  support;  limitation  of  an  automated  ai^ysis  subitem;  weakness  in  testing 
compile-time  performance;  and  lack  of  diagnostics,  debuggers,  and  a  library  system 

Ada  Evaluation  System 

The  AES  is  a  test  suite  designed  for  the  British  government  to  perform  testing  of  an 
Ada  programming  environment  Measurements  are  taken  on  features  sudi  as 
compile-  and  execution-time  performance,  generated-code  quality,  compiler-produced 
error  and  warning  messages,  linker  and  library  q^tems,  a^  debugging  capabilities. 
AES  strengths  are  breadth  of  coverage,  interactive  user  interface,  automatic 
generation  of  reports,  extensive  documentation,  macro  capability  for  test  generation, 
checklist  for  diagnostics,  library  systems,  vendor  evaluation,  and  examples.  AES 
shortcomings  are  considerable  setup  time,  lack  of  U.S.  support,  cost,  target  run-time 
performance,  and  the  subjective  nature  of  the  cheddist. 

4.d.U  Benchmarks 

All  compilers  are  not  alike.  Benchmarks  provide  techniques  and  application 
examples  to  compare  performance  among  different  Ada  compilers  or  performance 
among  Ada  compilers  and  other  language  compilers.  Cmefiil  analysis  of  the 
benchmark  result  will  help  identify  the  compiler  best  suited  for  the  conq>uting 
environment  of  a  given  project  To  guarantee  successful  benchmarking  the 
benchmarks  best  suited  to  project  requirements  must  be  selected  or  developed.  For 
some  medium  and  large  projects,  it  may  be  necessary  to  develop  benchinarks  that 
reflect  specific  project  needs.  Program  Managers  caimot  depend  solely  on  publicly 
available  resources;  th^  will  have  to  generate  some  of  their  own  benchmarks. 

When  selecting  and  developing  benchmarks,  the  Program  Manager  should  ensure  the 
following: 

•  Bendimarks  adequately  represent  and  test  the  system  requirements  and  the 
environment  selected. 

•  Benchmarks  are  part  of  a  plarmed,  total,  integrated,  supported  test  suite. 

•  Benchmarla  are  maintained  throughout  the  total  life  cyde. 

•  Bendimarks  and  benchmark  requirements  are  suitable  for  indusion  in  a 
contract 
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The  benchmark  developed  by  the  Performance  Issues  Working  Group  (PIWG)  of  the 
Association  for  Computing  Machinery  (ACM)  Special  Interest  Group  on  Ada 
(SIGAda)  comprises  a  suite  of  Ada  performance  measurement  programs  t^t  focuses 
primarily  on  the  execution  time  of  individual  features  of  the  Ada  language.  Mai^ 
tests  in  this  suite  are  designed  to  be  machine  independent  and  to  run  without 
modification.  These  tests  fall  into  the  areas  of  clock  resolution,  task  creation  and 
rendezvous,  (fynamic  storage  allocation,  exception  handling,  array  processing, 
procedural  and  run-time  overhead,  composite  benchmarks,  compilation  speed,  and 
oyiacity  test  The  strengths  of  the  PIWG  bendunark  are  ease  of  use,  wide  use,  wide 
distribution,  low  run  time,  and  no  cost  (it  is  free  through  the  DDN).  The  weaknesses 
of  the  PIWG  benchmark  are  lack  of  documentation  and  support 

The  Software  Engineering  Institute  (SEI)  is  developing  new  benchmarks  for  Ada 
applications. 

4.62  Availability  of  Project  Support  Environment  Standards 
Over  the  past  few  years,  national  and  international  standards  bodies  have  expended 
a  great  deal  of  technical  effort  to  define  reference  models  and  interface  standards 
for  PSEs,  such  as  those  discussed  in  Section  7.5.1  related  to  the  Project  Support 
Environment  Standard  Working  Group  (PSESWG),  Section  7.62  (i.e.,  Portable 
Common  Tool  Environment  [PCTE]),  and  Section  7.7  (i.e.,  Portsble  Common 
Interface  Set  [PQS]).  The  eventual  fruition  of  these  efforts  will  allow  greater 
modularity,  flexibility,  data  interchange,  and  openness  among  tool  suites  that 
constitute  PSEs.  The  Navy  Next  Generation  Computer  Resources  (NGCR)  program, 
described  in  Section  7Ji,  has  been  participating  in  the  definition  of  stand^ds. 

Until  these  standardization  efforts  are  more  mature,  the  tool  suites  that  constitute 
PSEs  for  Ada  (and  all  other  programming  languages)  will  be  product-driven. 
Consequently,  Program  Managers  need  to  carefully  manage  the  risks  that  may  be 
associated  wiA  the  following: 

•  Migrating  from  one  PSE  to  another 

•  Identifying  the  essential  elements  of  the  development-phase  PSE  that  must  be 
preserved  for  the  maintenance-phase  PSE 

•  Upgrading  various  elements  of  the  PSE  to  incorporate  the  latest  available 
technology. 

A  possible  interim  strategy  to  minimize  these  risks  is  to  select  PSE  tool  suites  from 
commercial  vendors  that  have  committed  to  support  these  emerging  national  and 
international  PSE  standards  in  their  product  lines. 
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4.63  TVwl  Up9»det  in  a  Praject  Sappoit  EBviitMUKBt 
During  the  project  life  cyde,  it  nuqr  be  <tesirable  to  iq)grade  (^ratipg  q^tems, 
conq>ilers.  editors,  CASE  tools,  and  the  Hke  to  the  latest  version.  The  Program 
Manager  is  responsible  for  controlling  sudi  upgrades  wisely  because  even  minor 
upgrades  can  have  serious  cost  and  sdiedule  repercussions. 

4.6.4  Mixing  Ada  With  Other  Languages 

DON  policy  piiHanffe  requires  the  use  of  Ada  in  major  software  upgrades  for 
flntnpiifgr  j^tems.  Choices  must  be  made  between  redesigning  and  recoding  all  of 
the  software  in  Ada  or  developing  a  strategy  to  support  ^tems  with  a  mixture  of 
Ada  and  other  languages. 

Completely  redesigning  and  recoding  the  ^tem  in  Ada  are  usualfy  cost-prohibitive 
activities  although  they  are  necessary  to  a^iieve  the  fiill  benefits  of  Ada.  Sinqrly 
translating  the  non-Ada  code  into  Ada  carries  the  risk  of  code  e}q)ansion 

does  not  take  advantage  of  the  many  software  engineering  features  of  Ada. 
rnhahitatinn  of  Ada  code  and  code  in  other  languages  appears  to  be  a  necessary 
ration— but  it  risk  and  requires  nm^  corporate  planning  and  conunitment 

One  approach  is  to  interface  existing  code  to  an  Ada  program  by  using  language 
interfaw  features.  In  this  case,  conqrflers  that  support  the  other  languages  nuist  be 
selected.  Mar^  compilers  have  excellent  interfaces  to  languages  sudi  as  COBOL, 
FORTRAN,  and  Pascal 

A  second  approach  is  to  isolate  the  unique  languages  by  the  processor  on  vdiich  they 
are  to  run  (Le.,  using  only  one  language  on  a  given  processor).  This  iqrproadi  allows 
interdiange  of  data  ^ough  message  passing  or  similar  methods  of  data 
normalization  and  is  a  low-risk  iqrproach  because  it  minimizes  the  need  to  change 
the  old  code  \riiile  eliminating  new  code  constraints.  For  this  iqqrroach,  conq>ilation 
^tems  for  each  of  the  language-processor  combinations  w^  be  needed.  This 
requirement  affects  PSE  selection  only  ^en  the  desire  is  to  have  a  single  PSE 
capable  of  supporting  all  of  the  languages  in  use  in  the  ^tem. 

4j63  Mixing  Executable  Ada  Programs  From  Diffemt  Compilers 
Another  class  of  problems  is  encountered  when  a  project  tries  to  mix  executable  Ada 
programs  from  two  or  more  commercial  conq>iler  systems  on  one  target  conqmter. 
In  general  such  programs  are  incompatible  because  of  the  differences  in  calling 
sequences  and  RTE.  One  iq)proach  to  this  problem  is  to  take  advantage  of  the 
portability  of  Ada  programs  at  the  source  level  In  this  way,  even  if  two  different 
compilation  tystems  were  used  to  develop  the  application  software,  all  source  code 
would  be  compiled  on  only  one  tystem  to  create  the  executable  software  for  the 
target  computer.  A  second  approach  is  m  define  an  interface  between  the  two 
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portioas  of  the  application.  In  this  way,  the  interface  can  resolve  the  inconq>atibility 
issues. 

4.7  IMPACT  ON  POST-DEPLOYMENT  SOFTWARE  SUPPORT 
Post-Deployment  Software  Support  (HDSS)  activities,  although  a  microcosm  of  the 
development  activities  in  scope,  general^  take  mudi  more  time  than  develc^ment 
activities.  Therefore,  effective  PDSS  requires  good  PSE  support  Althou^  few 
activities  or  functions  are  uitique  to  PDSS,  some  receive  more  or  less  enq>hasis 
during  PDSS  than  during  development  During  PDSS,  for  example,  generally  there 
is  a  heavy  emphasis  on  configuration  management  version  control,  and  regression 
testing. 

Transfer  of  the  software  product  from  the  development  to  the  PDSS  environment  is 
another  activity  that  must  be  examined.  If  the  two  PSEs  are  identical,  this  task  is 
much  easier.  Most  often,  however,  the  PSEs  will  be  different  Therefore,  the 
compatibility  between  the  software  tools  and  their  interfaces  becomes  a  very  real 
issue  that  must  be  solved. 
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Ada  and  Software  Engineering 

Rear  Admiral  Robert  M.  Moore,  the  Software  Executive  OfSdal  for  the  DqNutment 
of  the  Navy  (DON),  provided  an  ^ipropriate  introduction  for  this  section  in  a  q>eech 
to  the  Elevmith  Annual  National  Conference  on  Ada  Tedmology  on  18  Mardi  1993. 
Admiral  Moore  stated: 

In  the  past  several  decades,  computer  technology  has  pic^  an  important  and 
increadng  role  in  buSding  systems  whidt  maintain  our  military  superiority. 
However,  rite  software  to  run  these  ^ems  is  continuousfy  becoming  more 
complex,  more  etgtensive,  and  takes  kmger  to  devdop  At  one  rime,  it  was  the 
hardware  that  supported  the  missUm;  tode^,  the  hardware  is  rather  generic, 
ccpable  of  supporring  any  misaoru  It  is  the  software  that  provides  the  reed 
fimctiorudity. 

We  recoprize  the  need  to  improve  the  process  for  devehping  and  acquiring 
software  systems.  We  recognize  rite  important  of  software  enpneering  for 
devdopmgemdrrurintainmgourqtrtems.  And  we  rearprize  Ada  as  an  important, 
critical  tedmokqy,  necessary  to  support  good  software  enpneering. 

Cerurirriy,  good  software  enpneering  is  possible  without  Adeu  Using  Ada  does  rwt 
guaranty  good  software  engmeoing  but  Ada  as  a  building  block  for  software 
aipneeringdoesjuovidea  real  aqndiUity  to  develop  higft-quatity,  rehcrirle  ^ems 
to  sati^  our  mistion  in  rius  fleet  and  to  provide  a  real  capabUityfor  support  and 
rrurinterumce  ova-  the  entire  systam  l^e  cyde. 

Ada  arui  software  aigineering  have  been  importarri  to  the  Dqtartmerri  of  the  Navy 
in  the  past;  Ada  and  software  engineering  will  become  even  more  importatri  in  the 
fiOure  as  we  address  the  new  challenges  necessary  ta  transition  our  military  force 
from  one  ctqrable  of  defeating  a  stqrapowa  to  one  aqtable  of  rrutirttarring  peace 
in  an  environment  of  unrerrritting  Ifrird  World  conftontatUms. 

This  section  addresses  the  concept  of  software  engineering.  It  identifies  its  goals  and 
underlying  principles  and  lists  several  Ada  features  that  are  in^rtant  in  supporting 
software  engineering.  It  also  discusses  several  Ada  technology  issues  resulting  from 
good  software  engineering,  .^^ndix  L  and  its  attadunents  e]q)and  on  mar^  of  the 
ta|HCS  presented  in  this  section. 
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S.1  SOFIWARE  ENGINEERING  CONCEPT 

Good  ^sterns  engiiiceriiig  pracdoes  provide  a  framework  foi  good  software 
«mgiiMtf»ring  pracdoes.  The  Ada  language  was  q)ecifically  designed  with  features  to 
support  software  engineering. 

5.L1  Software  En^eering  Goals 

The  of  software  engineering  has  identified  four  goals,  supported  by  a 

mimhitr  of  Software  engineering  princ4>les,  to  help  manage  the  oon^>lex  task  of 
developing  modem  software  i^licadons.  Figure  5-1  presents  these  goals  and 
principles.  Ihe  four  software  engineering  goals  are  reliability,  modifiability, 
iin^-rstanHa^iility,  and  efficiency,  vdiich  are  defined  as  follows: 

•  ReUabiUty  is  associated  with  the  quality  of  the  software  and  is  a  cridcal  goal 
when  the  cost  of  failure  is  hi^.  Reliability  issues  must  be  addressed 
throughout  the  design  process.  Reliability  can  only  be  built  in  from  the  start; 
it  cannot  be  added  at  the  end. 

•  Mod^iabSity  deals  with  the  caqiability  to  perform  maintenance  on  or  otherwise 
change  the  software.  A  change  in  requirements  and/or  design  should  result  in 
a  entitro^^ed  change  in  the  software.  Error  correcdon  to  the  software  should 
be  effected  as  a  controlled  diange  to  the  software. 

•  Undmundability  h  key  to  tbtnmiBgcxatxit  of  complexity.  For  a  tystem  to  be 
undentandable,  it  must  reflect  our  natural  view  of  the  world.  At  a  high  level, 
objects  and  operadons  w»ap  to  real-world  data  and  algorithms.  At  a  low  level, 
the  software  sotudon  is  understandable  as  a  result  of  proper  coding  style. 

•  Efficiency  refers  to  the  use  of  resources.  Hme  and  ^ace  resources  should  be 
used  optimally.  This  goal  is  especially  in!q)ortant  when  real-time  deadlines 
must  be  met  to  satisfy  the  applicadon  requirements. 

5.L2  Software  Engineering  Principles 

The  software  engineering  principles  that  support  the  goals  of  software  engineering 
are  abstracdon,  dassificadon,  conq)leteness,  confirmability,  encapsulation, 
information  hiding,  inheritance,  localimdon,  modularity,  and  uniformity.  The 
definitions  of  these  principles  are  as  follows: 

•  Abstractitm  allows  users  to  highlight  the  essential  details  of  aprocess  or  its  data 
dependencies  and  omit  the  nonessendal  details.  In  this  manner,  the  logic  of 
a  program  solution  can  be  expressed  in  terminology  approximating  the  problem 
domain  rather  than  in  conqmter-dependent  terms.  Abstraction  supports  code 
readability  and  maintenance.  The  abstraction  principle  directfy  supports  the 
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goals  of  understandability  and  modifiability.  The  essential  details  can  be  filled 
in  later  without  affecting  the  balance  of  the  ^tem. 

•  Qas^ficahon  provides  a  means  h>  comprehend  the  real  worid  by  making 
generalizations  firom  discrete  observations.  Classes  are  organized  in  a 
hierardty  with  well-defined  interfaces.  This  princqile  is  a  cornerstone  of 
object-oriented  programming,  allowing  the  creation  of  specialized  objects  that 
inherit  the  properties  and  characteristics  of  an  object  dass.  Ada83  supports 
classification  with  the  use  of  additional  object-oriented  tools.  Ada  9X  has  been 
designed  to  effectivety  support  object-oriented  programming.  The  princ^le  of 
classification  supports  the  goals  of  reliability,  modifiability,  and 
understandability. 

•  Completeness  aeates  programs  that  entirety  satisfy  both  the  behavioral  and 
performance  software  requirement  Completeness  helps  us  develop  correa 
solutions  Ity  ensuring  that  all  of  the  important  elements  are  present  The 
principle  of  conq>leteness  supports  all  four  software  engineering  goals. 
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•  ConfvmabUity  verifies  that  the  q}plication  software  developed  satisfies  all 
requirements.  Each  software  system  must  be  readily  testable.  Decomposed 
^tems  can  localize  testing  and  thus  help  make  systems  modifiable.  Strong 
typing  facilities  help  the  confirmation  process.  Specialized  automated  tools 
that  understand  the  syntax  and  semantics  can  also  support  the  confirmation 
process.  The  principle  of  confirmability  also  supports  the  four  goals  of 
software  engineering. 

•  Encapsulation  allows  users  to  see  only  those  services  that  are  available  from  an 
object.  Access  to  objects  is  only  through  well-defined  interfaces. 
Implementation  details  are  hidden  from  the  user.  This  principle  is  closely 
related  to  abstraction,  information  hiding,  modularity,  and  local^tion.  The 
principle  of  encapsulation  supports  the  goals  of  reliability,  modifiability,  and 
understandability. 

•  Information  Hiding  makes  inaccessible  certain  details  that  do  not  affect  other 
parts  of  a  system.  For  example,  a  disk  drive  should  be  controlled  as  a 
collection  of  files,  but  an  application  should  not  control  a  disk  drive  by  using 
tracks  and  sectors.  Doing  so  could  violate  data  integrity  concepts  implemented 
as  part  of  another  process.  Reliability  of  tystems  is  enhanced  when,  at  each 
level  of  abstraction,  only  the  necessary  operations  are  permitted,  and 
operations  that  violate  a  logical  view  of  that  level  are  prevented. 

•  Inheritance  allows  the  properties  or  characteristics  of  an  object  class  to  be 
inherited  by  a  new  object  This  is  an  important  principle  necessary  to  support 
object-oriented  programming.  The  principle  of  classification  supports  the  goals 
of  reliability,  modifiability,  and  understandability. 

•  Localization  creates  programs  in  whidi  each  part  is  highly  cohesive  (i.e.,  critical 
data  are  self-contained)  and  loosely  coupled  (i.e.,  a  part  can  execute  in 
isolation).  Localization  enables  development  of  self-sufficient  components  that 
can  be  implemented  with  minimal  technical  interproject  and  intrsqrroject 
communication.  Modularity  and  localization  are  key  components  in  reducing 
expensive  project  communications  overhead  and  critical  to  incremental  build 
and  test  The  principle  of  localization  directly  supports  the  goals  of 
modifiability,  reliability,  and  understandability. 

•  Modularity  supports  the  organization  of  very  large  programs  into  discrete  parts, 
which  allows  separate  development  of  the  in^vidual  components.  The 
principle  of  modularity  directly  supports  the  goals  of  modifiability,  reliability, 
and  understandability. 
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•  Untfomity  refers  to  the  use  of  a  consistent  notation  for  all  artifacts  within  a 
software  development  activity.  Modules  are  free  from  any  unnecessary 
differences.  A  standard  coding  style  used  consistently  during  a  project  suf^rts 
the  principle  of  uniformity.  The  principle  of  uniformity  directly  supports  the 
goals  of  modifiability,  reliability,  and  u^erstandability. 

The  Ada  language  was  developed  to  support  the  software  engineering  goals  through 
features  that  draw  on  software  engineering  principles.  If  these  principles  are 
understood  thoroughly  and  applied  on  a  project,  use  of  Ada  can  effectively  support 
the  software  engineering  goals.  This  frtciHtates  effective  tystems  engineering. 

52  Ada  LANGUAGE  FEATURES  THAT  SUPPORT  SOFTWARE  ENGINEERING 
Ada  has  several  features  that  directly  support  software  engineering.  Appendix  L 
discusses  several  features  maity  people  consider  important,  including  Ada  packages, 
strong  typing,  exceptions,  generics,  Ada  libraries,  and  tasking.  The  programming 
examples  provided  illustrate  how  Ada’s  special  features  contribute  to  increased 
software  quality,  performance,  portability,  and  supportability. 

52  SOFTWARE  ENGINEERING  TECHNOLOGY  PRACTICES 
This  section  addresses  major  technology  practices  available  today  to  support  the 
software  development  and  maintenance  of  today’s  modem  systems.  The  relevance 
of  these  technology  practices  to  Ada  is  discussed. 

5J.1  Prototyping 

Use  of  prototyping  as  a  standard  technology  has  only  recently  become  widespread. 
The  surge  of  interest  results  from  the  availability  of  powerful  nonprocedural 
languages;  new  design  and  programming  tedmiques;  programming  languages,  such 
as  Ada,  that  promote  use  of  good  software  engineering  tedmiques;  and  &e  generally 
recognized  cost  and  reduced-risk  benefits  of  prototyping. 

A  prototype  may  be  defined  as  an  early  running  model  of  a  system  to  be  built.  This 
model  may  represent  only  a  very  small  portion  of  the  tystem,  such  as  the  interaction 
among  several  of  the  product’s  computer  display  screens,  so  that  the  evaluation  of 
user-friendliness  techniques  can  be  studied.  Or,  the  model  may  represent  a 
substantial  portion  of  the  tystem  so  that  many  of  the  functions  can  be  demonstrated. 

Prototyping  can  be  extremely  valuable  to  the  Program  Manager  in  defining  and 
evaluating  the  tystem  requirements,  espedally  with  respect  to  the  user  interface. 
Hands-on  experience  by  system  users  is  the  most  effective  way  known  of  validating 
requirements,  eliminating  ambiguities  in  requirements,  identifying  requirement 
defidendes,  and  analyzing  the  design  to  support  the  requirements. 
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5J.1.1  Purpose 

The  primaiy  purpose  for  building  a  prototype  is  usually  to  experiment  with, 
demonstrate,  or  prove  the  feasibility  of  a  concept  Prototypes  have  been  valuable  in 
conducting  the  following  activities: 

•  Evaluating  requirements 

•  Assessing  costs  of  alternative  design  sqjproaches 

•  Assessing  feasibility  of  a  specific  design 

•  Assessing  performance  for  alternative  design 

•  Determining  a  product’s  human-computer  interface 

•  Developing  and  fine-tuning  the  product  specifications 

•  Evaluating  interactions  of  parallel  threads  of  an  application 

•  Applying  new  technology 

•  Promoting  a  proposed  product  to  management  or  to  customers 

•  Obtaining  an  early  start  in  developing  a  new  product 

Prototyping  should  focus  on  assessing  and  redudng  the  risks  associated  with 
integrating  available  and  emerging  technologies  into  a  tystem  design  approach  to 
satisfy  a  validated  mission  need. 

Role  in  Evaluating  Requirements 

Prototyping  the  user  interface  before  Milestone  II  will  help  identify  whether 
specifications  to  satisfy  the  requirements  are  valid.  This  determination  allows  the 
development  activity  to  correct  any  deficiencies  in  the  user  interface  early  in  the 
program  where  changes  are  less  costly.  It  is  often  observed  that  what  looks  good  on 
paper  often  does  not  work  in  the  real  world.  Consequently,  each  improvement 
to  the  tystem  specifications  early  in  the  product  development  process  can  save  a 
significant  amount  of  rework  later.  Prototyping  the  user  interface  has  one  other  very 
important  benefit:  a  prototype  provides  an  opportunity  to  learn  bow  the  tystem  will 
behave,  in  order  to  further  explore  the  implications  of  the  system  requirements. 

5J.U  Prototyping  Considerations 

Generally,  all  systems  that  have  significant  interactions  with  end  users  and  exceed 
5,000  Source  Lhies  of  Code  (SLOC)  are  good  candidates  for  prototyping. 

^a  is  effective  in  supporting  most  prototyping  activities.  The  Ada  package,  which 
is  described  in  .^)pendix  L,  allows  sof^vare  engineers  to  rsqiidly  develop  an 
ardutecture  for  the  system  by  identifying  critical  interfaces.  A  stubbing  capability  in 
Ada  allows  code  to  be  separately  compiled  for  ease  in  devdoping  prototypes.  For 
XWmdows  environments,  Ada  Graphical  User  Interface  (GUI)  builders  are  available 
that  aUow  dynamic  creation  and  evaluation  of  the  user  interfaces. 
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Prototypes  intended  as  early  versions  of  the  final  application  should  be  designed 
appropriately  and  implemented  in  Ada.  When  prototypes  are  developed,  however, 
often  little  attention  is  paid  to  effectively  using  software  engineering  features. 
Certainly,  prototyping  should  never  be  an  excuse  for  hacking,  and  one  should  always 
have  honorable  purposes  in  mind  before  starting  a  prototype.  Prototyping  typically 
generates  poorly  designed  and  poorly  documented  code,  ai^  there  are  real  dangers 
in  converting  this  code  to  be  part  of  the  operational  software.  Generally,  code 
for  prototyping  is  unsuitable  for  supporting  an  operational  mission. 
Consequently,  even  when  Ada  is  used  for  a  prototype,  the  final  application  may  still 
require  appropriate  design  activities  that  use  software  engineering  principles. 

53JI  Simulators  and  Simulation  Languages 

Simulators  are  successfully  being  developed  in  Ada.  Ada  has  been  extensively  used 
in  the  flight  simulator  and  flight  trainer  domain.  In  the  past,  the  different 
environments  for  operational,  simulation,  and  training  software  resulted  in  different 
software  developed  for  each.  Ada’s  portability  and  modularity  of  desi^  provide  for 
significant  reuse  of  Ada  software  in  each  of  these  environments,  which  results  in 
savings  of  time  and  money.  Ada  also  is  suitable  for  operations  researdi  simulations 
and  modeling,  areas  traditionally  covered  by  special-purpose  simulation  languages 
such  as  SIMSCRIPT  and  GPSS.  The  use  of  Ada  requires  some  additional  effort  to 
provide  simulation  scheduling  and  report  generation,  which  are  provided  by 
traditional  simulation  languages.  Use  of  Ada,  however,  should  reduce  the  life-cycle 
maintenance  costs  of  these  simulation  and  modeling  programs.  Another  advantage 
is  Ada’s  tasking  (parallel  processing).  Tasking  is  effective  in  simulating  logically 
parallel  activities,  and  it  allows  multiple  processors  to  be  used  simultaneously  to  do 
the  work  previously  done  Ity  expensive,  high-powered  processors  (Law,  1992). 

533  Reuse 

Several  initiatives  are  underway  in  DOD  to  institutionalize  software  reuse.  This 
subsection  surveys  estimates  of  the  economic  benefits  of  software  reuse  and 
summarizes  some  reuse  techniques  and  issues  that  apply  to  Ada  software 
development.  In  addition.  Appendix  A.13  lists  several  government  and  DOD  reuse 
repositories. 

53  J.1  Economic  Benefits  of  Software  Reuse 

Attempts  have  been  made  to  quantify  the  economic  benefits  of  software  reuse  for 
software  development.  Estimates  of  potential  savings  range  fi’om  20%  to  more  than 
90%.  Most  experts  on  this  topic  agree  that  reuse  techniques  should  be  applied 
across  ail  phases  of  software  development  (i.e.,  requirements  definition,  design,  code 
production,  test,  and  Post-Deployment  Software  Support  [PDSS]  to  increase 
significantly  the  potential  for  cost  savings.  The  Software  l^gineering  Institute  (SEI) 
recently  published  economic  models  that  estimate  cost  savings  resulting  from 
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software  reuse  under  a  variety  of  conditions.  The  SEI  models  provide  a  qualitative 
analysis  of  conditions  needed  to  make  software  reuse  economicalty  benefidaL 

Software  Reuse  Techniques  ^plicable  to  Ada 
This  subsection  samples  current  techniques  in  software  reuse  that  can  be  applied  to 
Ada.  These  techniques  are  not  mutually  exclusive;  successftil  projects  have  ^opted 
concepts  and  methods  from  more  than  one  of  the  following  reuse  tedmiques: 

•  Development  of  Generic  Components  (megaprogramming) 

•  Design  techniques 

•  Commerdal  Off-The-Shelf  (COTS)  software. 

5  J.1  Development  of  Generic  Components  (M^programming) 

riassification  techniques  attempt  to  describe  how  a  software  repository  is  organized 
so  that  cnmpnnents  may  be  easily  identified  and  retrieved.  Domain  analysis,  a 
method  by  which  an  application  domain  is  decomposed  into  component  processes, 
is  one  such  technique.  The  resulting  collection  of  connected  processes  may  serve  as 
a  standard  for  organizing  a  reuse  library  of  that  domaiiL  Additional  information  on 
domain  analysis  is  available  in  "An  Object-Oriented  ^>proach  to  Domain  Analysis" 
(Shlaer  and  Miller,  1989).  This  technique  and  several  similar  techniques  describe  a 
reuse  repository  where  identifying  information  is  stored  in  n-tuplets  and  accessed  by 
a  query  tysterrt  Additional  information  on  this  technique  can  be  found  in 
"Classifying  Software  for  Reusability”  (Prieto-Diaz  and  Freeman,  1987). 

S3  J  J  J  Design  Techniques 

Information  hiding  is  a  design  technique  that  aUows  software  costs  to  be  significantly 
reduced  by  keeping  software  changes  as  localized  as  possible.  This  design  technique 
can  have  a  positive  impact  on  software  reuse  because  well-designed  Ada  packages 
containing  few  input  parameters  (hence,  less  need  for  information  from  the 
envirorunent  exter^  to  the  component)  are  more  likely  to  be  reusable.  A  corrunon 
example  would  be  the  abstraction  or  hiding  of  device-dependent  logic  from  other 
portions  of  the  program  so  that  the  other  portions  may  be  reused  easily  with  different 
devices. 

53333  Conunercial-Off-Tlie-Shelf  Software 

Reusing  COTS  software  is  another  technique  that  can  be  effectively  used  in  an  Ada 
software  development  When  COTS  software  meets  tystem  requirements  and 
aq>propriate  licensing  rights  can  be  acquired,  its  use  can  reduce  significantly  the  costs 
and  s^edules  associated  with  tystem  development  and  acquisition.  The  availability 
of  Ada  bindings,  described  in  ^pendix  H,  provides  a  firework  and  means  for 
effectively  integrating  COTS  soft>me  into  an  Ada  software  development  effort  Ada 
policy  encourages  the  use  of  COTS  software  (independent  of  its  underlying  language 
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inqilementation)  as  long  as  the  acquiring  program  office  does  not  modify  or  maintain 
the  CX)TS  software. 

5S33  Management  Issues 

Among  the  incentives  for  increasing  software  reuse  are  inq>roved  productivity 
because  less  code  development  is  required  and  improved  quality  because  previously 
tested  code  is  used.  Factors  that  inhibit  software  reuse  include  lack  of  a  standard 
software  architecture;  lack  of  trust  in  code  developed  elsewhere;  the  desire  to  use  the 
latest  innovative  languages,  tools,  and  approaches;  and  lack  of  knowledge  about  or 
difficulty  in  obtaining  information  on  available  tools,  software,  or  repositories. 

Domain  analysis  is  a  method  of  identifying  the  commonalities  and  variations  of 
existing  systems  within  the  same  application  area  to  determine  reuse  candidates. 
Domain  analysis  should  be  performed  as  part  of  the  requirements  analysis  to  gain  a 
better  understanding  of  existing  systems  in  terms  of  common  functionality  and  to 
identify  components  from  existing  s^tems  that  can  be  reused  in  the  current 
development.  Domain  analysis  conduaed  during  requirements  analysis  uncovers 
missing  requirements.  Addressing  these  missing  requirements  early  helps  to  stabilize 
the  requirements  package. 

The  issue  of  data  rights  is  sometimes  difficult  to  address.  A  piece  of  software  written 
by  an  employee  of  a  compaity  on  compaity  time  generally  belongs  to  the  conq>any. 
In  addition,'  if  software  development  is  contracted  out,  the  contract  should  specify 
who  owns  the  software  upon  delivery.  Program  Managers  should  ensure,  when 
reusing  software  from  another  source,  that  they  have  obtained  the  iq>propriate 
ownership  or  licensing  rights.  Another  data  rights  issue  that  should  be  considered 
is  the  responsibility  for  software  that  does  not  work  correctly.  This  is  an  issue  that 
the  Govermnent  faces  with  Govemment-Fumished  Equipment  (GFE).  When  the 
software  is  GFE  and  it  does  not  work,  the  Govermnent  may  be  responsible  for  any 
milestone  slips  or  additional  cost  resulting  from  the  software  probleriL 

S3A  Reeng^eering 

Reengineering  refers  to  the  redesign  of  one  or  more  elements  of  a  software  tystem 
to  improve  a  tystem’s  functionality.  Conversion  of  a  software  tystem  from  an  eristing 
programming  language  to  Ada  is  considered  a  form  of  reengineering.  A  variety  of 
reengineering  products  are  available  in  the  commercial  markeq>lace. 

Organizations  and  Program  Managers  responsible  for  long-term  maintenance  of 
DOD  software  systems  should  understand  the  relevance  and  potential  benefits  of  the 
reengineering  concept.  From  a  management  perspective,  use  of  automated  tools  is 
the  key  to  the  reengineering  process.  Where  tools  are  available,  tystem 
reengineering  can  be  performed  quickly  and  economically.  Reengineering  may  be 
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particularly  advantageous  in  situations  v/heie  large  libraries  of  non*Ada  code  exist 
Because  sdl  new  ^tems  and  any  major  modifications  to  existing  code  must  be 
developed  in  Ada,  organizations  with  software  maintenance  responsibilities  will  be 
required  to  maintain  expertise  in  both  Ada  and  the  programming  languages  of  their 
systems.  In  addition,  these  organizations  face  potentially  complex  and  costly 
integration  and  cohabitation  problems  as  th^  attempt  to  develop  and  operate  tqrbrid 
^tems  pnTisKting  of  Ada  and  non-Ada  code.  When  automated  tools  are  available, 
it  may  be  cost-effective  to  reengineer  all  existing  code  to  Ada  and  thereby  eliminate 
the  need  to  maintain  long-term  programming  e]q>ertise  in  other  languages.  The  costs 
and  technical  risks  of  interfacing  Ada  and  non-Ada  code  also  would  be  eliminated 
by  such  a  strategy. 

Ada  also  can  provide  excellent  interfaces  to  many  HOLs  and  assembler,  machine 
language,  and  system  services.  Although  this  capability  is  vendor  dependent,  it  can 
allow  for  an  effective  transition  strategy  to  Ada.  Sections  of  existing  non-Ada  code 
that  require  little  or  no  change  can  be  easily  incorporated  into  the  Ada  application. 

Reengineering  efforts,  however,  should  be  undertaken  cautiously.  Some 
reengineering  techniques  neither  provide  easily  readable  Ada  code  nor  take 
advantage  of  Ada  features.  No  firm  guidance  can  be  given  as  to  whether 
reengineering  is  the  right  option  for  a  particular  project  or  organization.  As  noted, 
the  commercial  market  is  well  stocked  in  reengineering  products.  Program  Managers 
need  to  familiarize  themselves  with  the  reengineering  marketplace  to  determine 
whether  reengineering  represents  a  viable  and  cost-effective  path  for  their 
organizations. 

53,5  Reverse  Engineering 

The  purpose  of  reverse  engineering  is  to  automatically  extract  the  design  information 
for  a  system  from  the  existing  system  source  code.  Currently,  reverse  engineering  is 
used  primarily  to  generate  documentation  products  to  help  manually  support  and 
modify  systems  by  using  existing  sotirce  code.  The  ultimate  goal  of  reverse 
engineering,  however,  is  to  extract  design  information  from  the  «dsting  system  in  a 
standard  design  format  with  an  automated  tool.  A  functionally  equivalent 
replacement  system  could  then  be  automatically  generated  the  tool  selected. 
Under  this  scenario,  any  required  change  to  the  ^tem  would  be  accomplished  at  the 
design-specification  level.  Several  products  are  emerging  on  the  market  to  support 
reverse  engineering. 

Industry  observers  generally  agree  that  this  type  of  capability  will  soon  become 
available.  The  emergence  of  this  type  of  tool  provide  Program  Managers  with 
an  additional  positive  option  to  deal  with  the  hybrid  Ada  and  non-Ada  code 
maintenance  problem.  It  will  soon  be  possible  to  improve  the  basic  design  and 
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structure  of  an  existing  ^tem,  incorporate  new  requirements,  and  then  regenerate 
the  entire  system.  As  with  the  reenpimering  market,  there  is  extensive  commercial 
activity  in  ^e  area  of  reverse  engineering  products.  Program  Managers  need  to 
maintain  familiarity  with  the  available  tedmology. 

53,6  Open  Systems  Environment 

The  following  discussion  is  based  on  the  U.S.  Department  of  Commerce,  National 
Institute  of  Standards  and  Technology  (NIST)  Application  Portability  Proffle  (APP), 
the  U.S.  Government’s  Open  System  Environment  Profile  OSE/1  Version  2.0;  and 
the  DOD  Technical  Architecture  Framework  for  Information  Management  (TAHM) 
Version  1.1 

Federal  information  tystems  initiaify  developed  from  isolated  islands  of  computing 
Through  progressive  Ganges,  these  individual  systems  became  connected  by  common 
users  and  common  information  needs.  These  systems  are  now  well  on  the  way  to 
migrating  toward  computing  environments  that  consist  of  distributed,  heterogeneous, 
networked  applications,  databases,  and  hau'dware.  The  concept  of  a  Fedend 
computing  environment  that  is  built  on  an  infinstructure  defined  by  open, 
consensus-based  standards  is  well  on  its  way  to  becoming  a  de  &cto  m«>ati<  of 
oigamizing  these  systems.  Such  an  infrastructure  is  called  am  Open  Systems 
Environment  (OSE). 

An  OSE  encompasses  the  fimctioiudity  needed  to  provide  interoperability,  portability, 
and  scalability  of  computerized  applications  across  networks  of  heterogeneous, 
multivendor  hardware/software/communication  platforms.  The  OSE  forms  an 
extensible  framework  that  allows  services,  interfaces,  protocols,  and  supporting  data 
formats  to  be  defined  in  terms  of  noiproprietaiy  specifications  that  evolve  through 
open  (public),  consensus-based  forums. 

53.6.1  Benefits  of  an  Open  Systems  Environment 

From  the  perspective  of  users  and  tedmologists  alike,  an  OSE  consists  of  a 
computing  support  infrastructure  that  fricilitates  the  acquisition  of  applications  with 
the  following  attributes: 

•  Execute  on  any  vendor's  platform 

•  Use  aity  vendor’s  operating  system 

•  Access  any  vendor’s  database 

•  Communicate  and  interoperate  over  any  vendor’s  networks 

•  Are  secure  and  manageable 

•  Interact  with  users  through  a  common  human-computer  interface. 
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In  more  technical  terms,  an  OSE  is  a  oon^ting  environment  that  supports  portable, 
scalable,  and  interoper^le  implications  through  standard  services,  interfoces,  data 
formats,  and  protocols.  The  standards  may  consist  of  inteniational,  national,  industiy, 
or  other  open  (public)  specifications.  These  specifications  are  available  to  aiqr  user 
or  vendor  for  use  in  building  systems  and  products  that  meet  OSE  criteria. 

in  an  OSE  are  scalable  among  a  variety  of  platform  and  network 
mtifigiirntionjt,  from  stand-alone  microcomputers,  to  large  distributed  ^tems  that 
may  include  microcomputers,  workstations,  minicomputers,  mainframes,  and 
supercomputers,  or  any  configuration  in  between.  The  existence  of  greater  or  fewer 
computing  resources  on  any  platform  will  be  apparent  to  users  only  in  the  context 
they  affect  the  application’s  speed  of  execution  (e.g.,  the  time  it  takes  to  refresh 
screens,  retrieve  data,  and/or  process  data). 

>^plications  interoperate  by  using  standard  communications  protocols,  data 
interchange  formats,  and  distributed  system  interfaces  to  transmit,  receive, 
understand,  use  information.  The  process  of  moving  information  from  one 
platform,  through  a  Local  Area  Network  (LAN),  Wide  Area  Network  (WAN),  or 
combination  of  networks  to  other  platforms  should  be  transparent  to  the  triplication 
and  the  user.  Location  of  other  platforms,  users,  databases,  and  programs  should  also 
be  transparent  to  the  application. 

In  short,  an  OSE  supports  applications  through  the  use  of  weU*defined  components, 
a  plug*compatible  technology  or  building-blodc  approach  for  developing  systems. 

Unfortunately,  not  enough  standards  are  in  place  to  define  an  OSE  completefy. 
Standards  organizations  are  working  on  this  problem,  but  much  effort  is  still  needed. 
As  technology  changes,  some  standards  will  become  obsolete  and  other  new  ones  will 
be  required.  Organizations  can  still  accomplish  a  great  deal  in  moving  toward  an 
OSE  by  selecting  specifications  he  will  provide  greater  openness  over  time. 

5J.6.2  Open  Systems  Environmeiu  Reference  Model 

The  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  POSIX  Working  Group 
P1003.0  describes  an  OSE  Reference  Model  (RM)  that  is  closely  aligned  with  the 
APP  that  provides  a  framework  for  describing  open  systems  concepts  and  defining 
a  lexicon  of  terms  that  can  be  agreed  upon  by  all  interested  parties.  Figure  5-2 
illustrates  the  OSE/RM. 

Two  types  of  elements  are  used  in  the  model:  entities  consisting  of  the  application 
software,  application  platform,  and  platform  external  environment,  on  the  one  hand, 
and  interfaces  including  the  application  programming  interface  and  external 
environment  interface  on  the  other  hand. 
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figure  5*2.  Open  Sjstans  Eariroanunt  Reference  Modd  (OSE/KM) 

The  duee  classes  of  OSE/RM  entities  axe  described  as  follows; 

•  Application  Software  includes  data,  documentation,  and  training. 

•  AppUauion  Platform  consists  of  a  collection  of  hardware  and  software 
components  that  provides  the  system  services  used  by  application  programs. 

•  Platform  External  Emnronment  contists  of  those  system  dements  that  ate 
external  to  the  application  software  and  the  plication  platform  (e.g., services 
provided  by  other  platforms  or  peripheral  devices). 

Two  classes  of  interfaces  in  the  OSE/RM  are  described  in  the  following  paragraphs. 

•  Application  Program  Interface  (API)  is  the  interface  between  the  application 
software  and  the  sqq)lication  platform.  Its  primary  function  is  to  support 
portability  of  application  software.  An  API  is  categorized  according  to  the  Qrpes 
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of  seivioe  accessible  thnni^  that  APL  The  four  of  API  services  in  the 
OSE/RM  are: 

-  Human-Conqmter  Interface  Services 
.  Information  bitercbange  Services 

.  Communication  Services 

-  Internal  System  Services. 

•  ExtenudEnvmmmentIfiteiface  (EEI)  is  the  interface  that  siq^rts  information 
transfer  between  the  qrplication  platform  and  the  external  environment 
Consisting  chie%  of  protocols  a^  supporting  data  formats,  it  siq)ports 
interoperability  to  a  large  extent  An  EEI  is  categorized  according  to  the  type 
of  information  transfer  services  provided.  The  three  types  of  information 
transfer  services  are  those  to  and  from: 

•  Human  users 

•  External  data  stores 

-  Other  application  platforms. 

&3.&3  i^plicatioB  Portability  Profile  Sovice  Areas 

A  selected  suite  of  spedfications  that  defines  the  interfaces,  services,  protocols,  and 
data  formats  for  a  {Muticular  class  or  domain  of  i^lications  is  called  a  profile.  The 
Application  Portability  Profile  (APP)  integrates  industry.  Federal,  national, 
international,  and  other  specifications  into  a  Federal  iqrplication  profile  to  provide 
the  functionality  necessary  to  acconunodate  a  broad  range  of  Federal  mformation 
tedmology  requirements.  The  APP  is  directed  toward  assisting  managers,  project 
leaders,  and  users  in  making  an  informed  judgment  regarding  the  ^oice  of 
q)ecifications  to  meet  current  requirements. 

The  services  defined  in  the  AFP  tend  to  fall  into  seven  broad  service  areas.  These 
service  areas  are: 

•  Operating  System  Services 

•  Ifriman*Computer  Interface  Services 

•  Software  En^eering  Services 

•  Data  Management  Services 

•  Data  Interchange  Services 

•  Graphics  Services 

•  Network  Services. 

Rgure  S>3  illustrates  where  each  of  these  seven  service  areas  relates  to  the  OSE 
Reference  ModeL  The  software  eiigineeriiig  services  are  not  shown  as  th^  are 
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applicable  in  all  areas.  Two  supporting  services  are  integrated  within  and  permeate 
the  other  seven  service  areas.  In  maiqr  cases,  separate  specifications  are  not  available 
for  these  supporting  services  within  each  of  the  seven  service  areas.  These  two 
services  are: 

•  Security  Services 

•  Management  Services. 

The  following  sections  briefly  define  eadi  service  area. 


Figure  5^.  APP  Service  Areas  and  the  OSE/RM 


S3.6J.1  Operating  System  Services 

Operating  tystem  services  are  the  core  services  needed  to  operate  and  administer  the 
s^lication  platform  and  provide  and  interface  between  application  software  and  the 
platform.  These  core  services  consist  of  kernel  operations,  commands  and  utilities, 
realtime  extensions,  and  system  management 


97 


Ada  Implementation  Guide 


Ada  and  Soflwara  Enginaaring 


53.63J  Httiiian*Coinpntar  Inteifue  Servkea 

Human-Con^uter  Interface  (HQ)  services  define  the  methods  by  which  people  may 
interact  with  an  application.  Depending  on  the  c^abilities  required  by  users  and  the 
q>pUcations,  these  interfaces  may  include  client-server  operations,  object  definition 
and  management,  window  management,  dialogue  supporf  and  multimedia. 

S3j633  Software  Engineering  Services 

The  objective  of  open  systems  is  to  produce  and  use  portable,  scalable,  interoperable 
software.  Software  engineering  services  provide  the  infrastructure  to  develop  and 
maintain  software  that  exhibits  the  required  characteristics.  Standard  programming 
languages  and  software  engineering  tools  and  environments  becoine  central  to 
meeting  this  objective. 

5J.6J.4  Data  Management  Services 

Central  to  most  systems  is  the  management  of  data  that  can  be  defined 
independently  of  the  process  that  creates  or  uses  it,  maintained  indefinitely,  and 
shared  among  many  processes.  Data  management  services  include  data  dictionary  or 
directory  services,  DataBase  Management  System  (DBMS)  services,  and  distributed 
data  services. 

Data  Interchange  Services 

Data  interchange  services  provide  specialized  support  for  the  exchange  of 
information  including  format  and  semantics  of  data  entities  between  applications  on 
the  same  or  different  (heterogeneous)  platforms.  Data  interchange  services  currently 
include  document  services,  graphics  data  services,  and  product  data  interchange 
services. 

5 J.6J.6  Graphics  Serrfces 

Grxq)hics  services  provide  functions  required  for  creating  and  manipulating  displayed 
images.  These  services  include  display  element  definition  and  management  and  image 
attribute  definition.  The  services  are  defined  in  specification  for  describing 
multidimensional  graphic  objects  and  images  in  a  form  that  is  independent  of  devices. 
Graphics  security  services  in  this  area  include  access  to,  and  integrity  of,  functions 
that  support  the  development  of  imaging  and  graphics  software  and  image  data. 

53.6  J.7  Netwoilc  Services 

Network  services  provide  the  capabilities  and  mechanisms  to  support  distributed 
:q>plications  requiring  data  access  and  applications  interoperabili^  in  heterogeneous, 
networked  environments.  These  services  include  the  data  communication,  transparent 
file  access,  PC  or  microcomputer  support,  and  remote  procedure  call. 
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Security  Services 

Security  services  are  provided  to  support  distribution  and  integrity  of  information  and 
to  protect  the  computing  infrastructure  from  unauthorized  access.  These  services 
include  operating  system  security  services,  HQ  security  services,  programming 
security  services,  data  management  security  services,  data  interchange  security 
services,  graphics  security  services,  and  network  security  services. 

53*63S  Management  Services 

Management  services  are  integral  to  the  operation  of  an  OSE.  Th^  provide  the 
to  monitor  and  control  the  operation  of  individual  ^plications, 
tystems,  platforms,  networks,  and  user  interactions  with  these  components. 
Management  services  enable  users  and  tystems  to  become  more  efficient  in 
performing  required  work.  Management  is  better  able  to  streamline  the  operation, 
administration,  and  maintenance  of  open  systems  components.  These  services 
include  fault  management  and  control  services,  configuration  control  services, 
accounting  services,  and  performance  monitoring  services. 

53,7  System  Portability 

Portability  refers  to  the  ease  with  which  software  can  be  transferred  from  one 
computer  system  or  environment  to  another.  Over  the  life  of  an  application 
program,  the  host  development  environment  frequently  dianges  because  of  hardware 
upgrades,  modernization,  and  the  transition  of  support  from  a  contractor  to  a 
government  facility.  Portability  must  be  considered  when  selecting  or  developing 
tools  and  software. 

Porting  from  one  hardware  environment  to  another  presents  special  portability 
problems  because  word  sizes  may  be  different,  which  affects  numeric  representation 
and  accuraty,  and  architectures  are  different,  which  affects  interrupt  processing, 
interfaces,  and  bus  commands.  Porting  from  one  software  environment  to  another 
can  also  pose  special  problems.  For  example,  operating  system  calls  and  interprocess 
communications  differ  significantly  among  different  operating  tystems. 

Ada  code  is  perhaps  more  portable  than  any  other  language  because  of  Ada’s 
validation  suite  and  the  capability  to  isolate  tystem  dependencies  through  Ada 
packages.  Because  of  a  comprehensive  conformance  test  suite  involving  more  than 
4,000  tests,  a  high  level  of  uniformity  is  achieved  among  validated  Ada  compilers. 
Furthermore,  hardware  and  software  dependencies  can  be  isolated  in  a  small  number 
of  modules.  With  appropriate  isolation  of  these  dependencies,  the  number  of 
modules  requiring  change  to  support  porting  from  one  compiler  to  another  can  be 
very  small. 
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NobelTech  recentfy  conducted  a  poitabili^  exercise.  In  this  exercise,  about  6,000 
Ada  modules  written  for  the  Motorola  68020  chip  were  ported  to  the  Reduced 
Instruction  Set  Computing  (RISC)  architecture.  Of  these  6,000  modules,  onfy  about 
30  modules  required  sourra  code  changes  for  the  port  .^>pendix  I,  Section  L8, 
highlights  the  complexities  involved  in  achieving  portability  in  the  Tactical  Aircraft 
Mission  Planning  System  (TAMPS). 

53  J  Ada  Compared  to  Assembler 

Coding  with  High  Order  Languages  (HOLs)  such  as  Ada  has  important  benefits 
when  compared  to  coding  in  Assembly.  McDonnell  Douglas  demonstrated  these 
benefits  for  the  computation  of  the  Structural  Filter  as  part  of  the  F-15  integrated 
flight  control  system,  which  was  flown  in  September  1984.  Appendix  L  provides  this 
example. 

From  this  example,  it  is  clear  that  the  Assembler  code  would  be  veiy  prone  to  error. 
A  highly  skilled  Assembler  programmer  is  likely  to  make  several  errors  just  coding 
this  small  example.  It  is  virtually  impossible  for  a  nonprogrammer  to  look  at  the 
code  and  make  sense  of  it.  In  contrast,  the  Ada  code  looks  almost  identical  to  the 
code  coming  out  of  the  system  specification;  therefore,  any  errors  are  likely  to  be 
detected  easily  during  design  reviews.  Code  generated  in  Ada  is  more  reliable  and 
has  a  higher  quality  than  code  generated  in  Assembly.  Incidentally,  McDonnell 
Douglas  projected  an  order  of  magnitude  improvement  in  programmer  productiviQr 
using  Ada  rather  than  Fixed  Point  Assembly  Language  for  design,  coding,  and  testing. 

Project  Managers  expect  that  Assembly  code  can  be  made  to  execute  much  faster 
than  Ada  code.  In  most  situations,  this  is  not  true.  Today,  optimizing  compilers  can 
generate  Ada  executable  code  that  is  much  faster  than  that  done  in  Assembly.  A 
highly  skilled  Assembly  programmer  will  not  normally  find  all  of  the  places  where 
optimization  can  manually  be  coded;  an  optimizing  compiler  will.  Occasionally,  a 
highly  skilled  Assembly  programmer  can  generate  slightly  more  efficient  code, 
especially  in  tight  loops  where  there  are  interfaces  to  nonstandard  hardware.  Ada 
provides  an  excellent  interface  to  machine-level  code  so  that  this  can  be  done  when 
required. 

S3S  Ada  Compared  to  C,  €+  + 

In  1991,  the  Air  Force  conducted  a  Business  Case  Analysis  to  compare  Ada  to  0+  + 
to  determine  under  what  circumstances  a  waiver  to  the  DOD  Ada  requirement  might 
be  warranted  for  use  of  C++,  particularly  in  the  DOD’s  Corporate  Information 
Management  (CIM)  Program.  This  report  examined  quantitatively  the  availability 
of  tools,  language  selection  methodologies,  rost,  and  the  emerging  impact  of  fourth- 
generation  technology.  Each  study  reached  the  same  conclusion:  there  is  no 
compelling  reason  to  waive  the  Ada  requirement  to  use  C++. 
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The  report  summary  stated  that  it  is  impossible  to  make  a  credible  case  fmr  the 
existence  of  more  cost-ejfective  C-¥+  ^tems  compared  to  Ada.  Business 
cost<effectiveness  data  collected  for  the  stutfy  showed  that  Ada  provides  development 
cost  advantages  on  the  order  of  35%  and  maintenance  cost  ad^tages  on  the  order 
of  70%. 

A  March  1991  SEI  study  compared  Ada  to  C  and  C-i-  +  in  the  areas  of  curability, 
efficient,  reliability,  maintainability,  lifecycle  cost,  and  risk  (Camegie-Mellon 
University,  1991).  Ada  83  compared  quite  well  to  +  as  Figure  5<4  depicts. 


C4-I- 


Source:  Camegie-Mellon  University/Software  Ea^eering  Institute,  1991 

FlgUK  5-4.  Conparison  Ada  to  C-f  4-  (SEI,  1991) 


A  report  from  New  York  University  in  April  1992,  titled  Contrasts:  Ada  9X  and 
C+  +  indicated  that: 

Ada  9X  had  similar  advantages  over  C++,  particularly  when  software  costs 
were  examined  over  the  lifetime  of  the  software  system.  Ada  9X  was  also 
found  to  be  superior  in  terms  of  safety  and  reliability.  A  copy  of  this  report 
can  be  obtained  through  the  AdalC,  wMch  is  described  in  Appendix  A,  Section 
A.1.1. 
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5J.10  Mbdng  Ada  With  Other  Languages 

One  of  the  major  challenges  to  the  more  widespread  use  of  Ada  within  DOD  is  the 
large  number  of  non-Ada  systems  that  are  being  reengineered  or  upgraded.  The 
number  of  new  starts,  as  compared  to  upgrades,  is  very  low.  Even  for  new  starts, 
often  the  strategy  is  to  make  ^e  greatest  possible  use  of  existing  code. 

Several  Ada  features  support  interfaces  to  other  languages.  Interfaces  to  languages 
such  as  C,  FORTRAN,  COBOL,  Pascal,  and  Assembly  are  common.  Such  interfaces 
are  vendor  dependent  and  may  not  be  portable  from  one  compilation  system  to 
another.  If  such  capabilities  are  desired,  one  should  check  with  the  compiler  vendor 
for  support  of  Pragma  INTERFACE  for  the  desired  language(s). 

The  National  Aeronautics  and  Space  Administration  (NASA)  has  been  successful  in 
mixing  Ada  with  other  languages.  They  have  a  considerable  investment  in  legacy 
software  written  in  FORTRAN,  C,  and  Pascal.  By  making  use  of  an  Ada 
infrastructure,  NASA  is  able  to  reuse  much  of  this  legacy  software  and  take 
advantage  of  the  software  engineering  benefits  of  an  Ada  architecture. 

5.4  PARADIGM  SHIFTS  FOR  EFFECTIVE  SOFTWARE  ENGINEERING 
Correct  orientation  in  education  and  training  is  critical  in  tapping  the  strengths  of 
Ada  that  can  help  us  achieve  a  paradigm  shift  to  effective  sofnvare  engineering. 

In  its  shallowest  sense,  Ada  is  just  another  programming  language.  If  software 
developers  are  introduced  to  it  in  this  context,  it  will  be  of  little  benefit  Taught  in 
the  context  of  a  tool  to  support  good  software  engineering  practices,  however,  it  can 
be  of  great  benefit.  In  short  it  is  the  paradigm  shift,  the  cultural  change,  m  how  to 
develop  software  ^sterns  that  is  imperative  and  will  bring  the  most  gains.  Ada  is 
simply  one  of  the  most  effective  tools  at  our  disposal  to  support  this  shift.  To 
support  this  paradigm  shift,  education  and  training  programs  must  focus  on  software 
engineering  and  teach  Ada  in  the  context  of  a  tool  to  support  it. 
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Lessons  Learned 

This  section  suminarizes  the  ooUecdve  set  of  lessons  learned  on  several  Department 
of  Defense  (DOD)  and  commercial  Ada  projects,  including  the  following: 

•  Stratcom>Computer  Center,  Offiitt  Air  Force  Base 

•  Wells  Fargo  Nikko  Investment  Advisors 

•  B-2  Aircrew  Training  Devices 

•  Boeing  Militaiy  Aircraft  (Wichita,  Kansas) 

•  Coulter  Electronics:  Ada  for  Cytometry 

•  AN/UYS*2A  Project 

•  Ada  E)g)erience  at  the  Naval  Researdi  and  Development  Center 

•  Tactical  Aircraft  Mission  Planning  System 

•  Advanced  Field  Artilleiy  Tactical  Data  System 

•  AN/BSY-2  Submarine  Control  System 

•  Ada  Language  System/Navy  Full-Scale  Development  Program 

•  Avionics  Project  for  an  Airborne  Command,  Control,  and  Intelligence 
Application 

•  PEO-SSAS,PMS-414,  SEA  LANCE 

•  Navy  World  Wide  Military  Command  and  Control  System  (WWMCCS)  Site- 
Unique  Software  Project 

•  Event-Driven  Language/COBOL-to-Ada  Conversion  Program 

•  Shipboard  Gridlodc  System  with  Auto-Correlation 

•  Combat  Control  System  MK2 
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•  P-3C  Update  IV  Ada  Development 

•  Standard  Financial  System  Redesign 

•  Reconfigurable  Mission  Computer  Project 

•  Intelligent  Missile  Project 

y^ipendix  I  provides  a  full  description  of  these  projects  and  the  lessons  learned  on 
fafh  This  appendix  also  provides  a  matrix  showing  the  lessons  learned  by  specific 
category  and  project  As  review  of  this  ^rpendix  shows,  most  of  the  problems 
encountered  were  management-related,  not  Ada-specific,  problems.  In  addition, 
some  problems  recur  across  all  of  these  projects,  sudi  as: 

•  Lack  of  training  and/or  experience 

•  Failure  to  take  a  risk  engineering  approach 

•  Tmpmpgrly  specified  contract  requirements  for  software-related  items  and 
processes 

•  Inadequate  estimates  of  resources  and/or  facilities  needed 

•  Immaturity  of  Ada  development  tools  and  environments 

•  Insufficient  incremental  testing  or  lack  thereof. 

The  subsections  below  highlight  a  few  of  the  lessons  common  to  several  of  the 
projects  in  the  areas  of  standards  and  poli^,  project  management,  development 
process,  corporate  knowledge  ^  software  development  ejqwrience,  training, 
resources  and  facilities,  support  environment  tools,  reuse,  and  project  costs. 

Before  imdertaking  any  software-intensive  tystem  development,  the  reader  should 
review  the  matrix  in  ^pendix  I,  and  the  Project  Manager  should  study  the  detailed 
project  descriptions  in  this  appendix  so  as  to  benefit  from  the  lessons  learned. 

6.1  STANDARDS  AND  POLICY 

Lesson  Area  Summary:  Review  of  the  project  lessons  shows  the  necessity  for 
establishing  a  policy  to  ensure  that  planning  and  monitoring  of  software  development 
occur  early  in  the  development  process.  The  lessons  also  highlight  the  importance 
of  incorporating  the  critical  elements  of  the  Military  Standards  into  the  acquisition 
padcage  (e.g.,  the  Request  for  Proposals).  In  addition,  the  lessons  suggest  that 
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policies  be  established  to  require  i-'  .'remental  development,  use  of  metrics  from  the 
begiiming  of  the  project,  and  i  iment  of  a  common  s^le  guide  for  use  across 
development  teams. 

Continuing  Challenges:  DOD  acquisition  policies  have  recently  been  revised.  It  is 
still  too  early  to  assess  the  overall  impact  of  these  revisions  on  acquisition 
management  practices.  Emerging  policies  and  standards  that  deal  with  software 
reuse.  Open  Systems  Architecture  (OSA),  information  ^tem  security,  tools,  and  use 
of  Nondevelopmental  Item/Commerdal-Off-The-Shelf  software  will  directly  affect 
software  acquisition  practices. 

62  PRO JECT  MANAGEMENT 

Lesson  Area  Summary:  Nearly  every  lesson  learned  in  these  projects  related  to 
project  management,  as  the  matrix  in  Figure  I-l  in  Appendix  I  ^ows.  Among  the 
recurring  lessons  in  this  area  is  the  need  for  up-front  planning  and  close  monitoring 
of  the  project  Also  evident  and  related  to  up-front  planning,  is  the  necessity  for 
ensuring  that  adequate  fticilities  and  resources  are  available. 

Continuing  Challenges:  Within  the  area  of  project  management  new  and  strong 
emphasis  is  being  placed  on  the  early  assessment  and  evaluation  of  true  life-^de 
costs.  Among  the  topics  being  addressed  are  evolutionary  (lower  risk)  developments; 
risk  planning  and  control;  complete  metrics  programs;  increased  use  of  commercial, 
nonpropiietaiy  software,  hardware,  and  networking  interface  standards;  optimized 
softie  portability;  and  design  for  reuse.  As  in  the  past  the  need  to  ensure 
adequate  stafBng,  resources,  and  facilities  to  accomplish  the  work  must  be  anticipated 
and  addressed.  These  key  ingredients  all  need  to  be  incorporated  into  a  well- 
thought-out  early  planning  effort  Once  execution  begins  (based  on  a  complete  Work 
Breakdown  Structure  [WBS]),  status  and  progress  towards  interim  deadlines  must  be 
continuously  monitor^. 

62  DEVELOPMENT  PROCESS 

Lesson  Area  Snmmaiy:  The  most  significant  lesson  learned  across  projects  was  the 
inqmrtance  of  implying  sound  tystems  engineering  and  software  development 
practices  and  principles  at  eveiy  stage  of  the  project  Of  particular  inq>ortance  is 
strict  adherence  to  configuration  management  and  Quality  Assurance  practices.  On 
several  projects,  use  of  a  consistent  methodology  and  adoption  of  a  risk  engineering 
approach  were  mentioned  as  k^  to  a  successful  development  process. 

Continuing  Chailenges:  Greater  flexibility  in  the  development  process  is  being 
allowed  in  toda/s  acquisition  environment  The  days  of  starting  software 
developments  from  scratch  and  blindly  imposing  a  waterfrdl  development  process 
have  passed.  Advances  in  object-oriented  design,  OSA  interfacing,  and  lega^ 
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software  availability  enable  tystems  to  evolve  through  reuse  and  modular  upgrades. 
The  willingness  to  actively  pursue  "joint"  or  "shared"  developments  should  lead  to 
lower  risk,  deaeased  cost^  and  improved  quality  in  meeting  mission  requirements. 

6A  CORPORATE  KNOWLEDGE  AND  SOFTWARE  DEVELOPMENT 
EXPERIENCE 

Lesson  Area  Summaiy:  In  this  area,  the  lessons  learned  emphasize  that  both 
Government  and  contract  developers  must  understand  the  project  requirements  and 
adhere  to  them.  Corporate  knowledge  and  software  development  experience  also  are 
needed  to  establish  schedules,  determine  at  what  point  full-blown  coding  should 
begin,  and  identify  the  resources  available  to  meet  tystem  requirements. 

Continuing  Challenges:  Knowledge  of  the  corporate  domain  and  ancillaiy  software 
development  experience  continue  to  be  critical  to  the  generation  and  deployment  of 
software-based  systems.  Such  experiential  data  and  information  need  to  be  captured 
as  they  are  generated,  saved  in  the  impropriate  context,  and  recalled  when  needed. 
Armed  with  this  collective  knowledge,  plaimers  can  make  informed  estimates  of  the 
what,  how,  when,  and  why  for  new  undertakings.  The  goal  here  is  to  transition  both 
the  engineering  and  management  of  systems  development  from  the  worst  case 
"initial"  to  the  "optimizing"  or  continuous  process  improvement  level.  Such  a 
conversion  will  ensure  best-quality  products  and  maximum  potential  to  anticipate 
future  change. 

6S  TRAINING 

Lesson  Area  Summary:  On  several  of  the  projects,  the  need  for  Ada-specific  training 
was  noted  because  most  of  the  experienced  persoimel  have  little  or  no  experience 
with  Ada  and  modem  software  engineering  practices.  This  need  for  training  ^)p^^ 
to  both  technical  and  management  persoimeL  Project  ejq>erience  suggests  that 
hands-on  training  should  be  conducted  as  dose  as  possible  to  development  or  during 
development 

Continuing  Challenges:  Ada-specific  training  problems  should  decrease  over  time. 
Training  in  application  software  engineering  process  methods  and  use  of  Computer- 
Aided  Systems  Engineering  (CASE)  tedmology  tools,  however,  needs  to  be 
addressed  for  both  technical  and  management  persoimel. 

6.6  RESOURCES  AND  FACILITIES 

Lesson  Area  Summaiy:  As  mentioned  above,  review  of  the  project  lessons  indicates 
that  the  initial  estimates  of  the  resources  and  fodlities  needed  often  were  inadequate. 
Project  e]q>eriences  show  the  necessity  for  having  developers  identify  the  tools  to  be 
used  in  both  tystem  analysis  and  development  to  ensure  adequate  resources  will  be 
available  to  meet  requirements. 
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Continuing  Oiallenges:  Resource  and  facility  planning  must  address  both 
development  and  post-deployment  maintenance  needs.  For  larger,  geographicalty 
distributed  developments,  the  lowest  risk  solution  is  to  standardize  as  many  of  the 
support  resources  as  possible,  including  tools,  exchange  media,  documentation, 
processes,  configuration  management,  and  environments.  Managers  need  to  develop 
resource  utilization  estimates  before  beginning  projects,  and  they  need  to  monitor 
utilization  closely  to  track  actual  consumption  against  projections. 

6.1  TOOLS 

Lesson  Area  Sunimaiy:  For  large,  geographically  dispersed  projects,  the  lessons 
learned  show  that  common  support  tools  should  be  required.  Use  of  common  tools 
allows  problems  to  be  identified  quickly,  workarounds  made  only  once,  and  results 
entered  into  a  shared  electronic  reporting  system.  In  addition,  before  committing  to 
large  projects,  the  methods  and  tools  should  be  exercised;  the  team  must  be  well 
trained  in  the  use  of  the  supplied  tools;  and  the  tools  must  work  as  advertised. 
Project  experience  also  indicates  that  use  of  automated  tools  should  be  mandatoiy 
for  large  software  undertakings  and  that  development  tools  are  essential. 

Continuing  Chalienges:  The  nmnber  of  vendor  tool  products  continues  to  increase 
as  the  industiy  matures  and  enters  its  second  decade.  Many  products  on  the  market, 
however,  fail  to  meet  the  goal  of  total  life-^cle  support  Integrated  data  and 
information  exchange,  along  with  interoperability  among  differing  vendor  tools, 
remains  elusive.  For  CASE  tools,  project  experience  has  also  shown  that  unless 
proper  evaluation,  selection,  training,  and  management  commitment  occurs,  the 
products  are  sometu^es  abandoned  because  of  poor  performance  and  lack  of  utility. 

6J6  REUSE 

Lesson  Area  Summary:  The  project  lessons  show  that  Ada  facilitates  reuse  and  that 
planning  for  and  designing  in  reuse  yield  long-term  benefits.  It  was  noted  that 
development  and  maintenance  time  can  be  reduced  significantly  by  capitalizing  on 
reuse.  However,  project  experience  suggests  that  large-scale  software  component 
reuse  will  depend  on  achieving  more  technological  progress. 

Continuing  Challenges:  Within  the  past  2  years,  concern  about  the  affordability  of 
systems  and  the  need  for  evolutionary  upgrades  has  escalated.  In  response  to  that 
concern,  the  efforts  to  promote  reuse  have  increased  dramatically.  Tool  technology 
has  begun  to  provide  automated  ways  of  designing  for  reuse  and  evaluating  lega^ 
software  assets.  As  with  CASE  technology,  key  ingredients  for  success  include 
corporate  commitment,  planning,  resource  investment,  engineering  and  management 
discipline,  and  correct  tool  selection  and  usage. 
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PROJECT  COSTS 

Letsoo  Area  Sammaiy:  On  several  projects,  the  effect  of  inadequate  initial  estimates 
of  the  needed  resources  had  cost  inqilications.  In  some  cases,  additional  funding  was 
needed  for  support  hardware  a^  fodlities  and  for  training  as  well  as  to 
accommodate  schedule  delays. 

Continuing  Challenges:  The  inqiending  cuts  in  the  overall  DOD  budget  will  make 
it  necessary  to  learn  how  to  accomplish  more  with  less.  The  number  of  start-from- 
scratch  projects  will  decrease  whereas  the  need  to  plan  carefully  for  smaller  upgrades 
of  existing  systems  will  increase.  There  will  be  a  much  greater  enq>hasis  on 
demonstrating  a  new  concept  before  allowing  full  production  to  proceed,  b  such  an 
environment,  funds  will  need  to  be  invested  to  ensure  developers  fully  understand 
existing  products  and  their  c^abilities.  From  a  software  perspective,  investment  in 
domain-specific  software  reuse  needs  to  be  acrelerated.  In  addition,  the  downscaling 
of  worldwide  threats  should  cause  reallocation  of  funds  away  from  only  mission- 
driven  requirements  to  a  more  even-handed  set  of  requirements  that  addresses 
mission,  quality,  and  affordability. 
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Future  Directions 

Evolviiig  technology  is  valuable  to  Program  Managers  as  the  latest  initiatives  become 
the  state  of  the  practice.  Several  important  initiatives  are  examining  ways  to  inqtrove 
the  software  development  process,  increase  productivity,  increase  quality,  and  reduce 
costs.  These  initiatives  will  be  important  to  the  Department  of  the  Navy  (DON)  in 
the  near  future. 

This  section  provides  a  description  of  the  following  initiatives,  which  warrant 
attention: 

•  Ada9X 

•  Ada  Reuse 

•  Corporate  Information  Management  (OM) 

•  Integrated  Computer-Aided  Software  Engineering  (I-CASE)  tools 

•  Next  Generation  Computer  Resources  (NGCR)  _ 

•  North  American  Portable  Common  Tool  Environment  (PCTE)  Initiative 
(NAPI) 

•  Portable  Common  Inter&ce  Set  (PQS) 

•  Software  Engineering  Institute  (SEI) 

•  Software  Executive  Official  Council  (SEOC) 

•  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 

•  Tactical  Advanced  Computer-4  (TAC-4)  and  TAC-S  Procurement 

•  Technology  plans,  including: 

-  Software  Action  Plan  (SWAP) 

-  Software  Technology  Strategy  Document 

-  DON  Reuse  Implementation  Plan  and  Guide 

-  DON  Information  Management  Strategic  Plan 

-  DON  Software  Process  Inq)rotwment  (SPI)  Plan 

•  DON  Tedmc'ogy  Pilots,  including: 

-  I-CASE  PUots 

-  Functional  Process  Improvement  (FPI) 

-  SEI  PUots 

-  STARS  Demonstration  PUot 
7.1  Ada9X 

The  tenets  of  both  the  American  National  Standards  Institute  (ANSI)  and  the 
International  Organization  for  Standardization  (ISO)  require  that  each  standard  be 
periodicaUy  revisited.  Ada  9X  is  the  effort  to  perform  this  function  for  the  Ada 
programming  language. 
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7.1.1  Background 

The  Ada  language  standard,  ANSI/Militaiy  Standard  (MIL-STD)-1815A,  was 
published  in  1983.  Starting  in  1984,  the  number  of  available  Ada  development 
facilities  began  to  increase.  As  Ada  was  rigorously  used  in  several  projects,  a  series 
of  omissions,  limitations,  and  minor  errors  were  identified.  In  January  1988,  the  Ada 
Joint  Program  Office  (AJPO)  asked  the  Ada  Board  for  a  recommendation  on  how 
to  resolve  this  situation. 

In  September  1988,  the  Ada  Board  delivered  its  report,  which  recommended  revising 
the  language.  To  accomplish  this  task,  the  Ada  9X  Project  Office  was  established 
under  the  direction  of  Christine  M.  Anderson  at  Eglin  Air  Force  Base  (AFB), 
Florida,  and  was  relocated  to  Kirtland  AFB,  New  Mexico,  in  July  1992.  The  goal  of 
the  project  is  to  revise  Ada  83  and  effect  a  smooth  transition  from  Ada  83  to  Ada 
9X  (ANSI/MI1^STD-181SB).  During  the  project,  a  public  survey  was  conducted  to 
solicit  revision  requests,  and  more  than  750  revision  requests  were  received.  Several 
international  workshops  were  convened  to  review  and  rank  those  inputs. 

Changes  have  been  constrained  by  the  overall  objective  of  minimizing  the  negative 
impact  and  maximizing  the  positive  Impact  on  the  Ada  community.  Upward 
compatibility  between  Ada  83  and  Ada  9X  is  a  high-priority  goal.  The  effect  on 
managers,  programmers,  vendors,  educators,  authors,  and  various  application  domains 
will  be  considered  throughout  the  revision  process. 

The  revision  will  include  only  those  changes  that  improve  the  usability  of  the 
language  while  minimizing  the  disruptive  effects  of  changing  the  standard.  The 
revision  process  will  continue  and  will  include  various  forms  of  public  scrutiny  such 
as  conferences,  electronic  mail  comments,  and  draft  documentation.  The  draft  Ada 
9X  standard  will  be  released  for  voting  by  ANSI  and  ISO  in  September  1993.  ANSI 
and  ISO  approval  of  the  revisions  is  expected  in  1994. 

7.1.1.1  Requirements 

The  proposed  revision  requirements,  which  were  completed  in  December  1990,  are 
grouped  into  the  following  categories: 

•  General  requirements.  Collection  of  small  defects  in  the  language  with  the 
structure  and  format  of  the  standard  retained 

•  Real-time  requirements.  Precise  control  over  when  an  action  occurs 

•  Systems  programming  requiremertts.  Machine  operations,  data  interoperability, 
interrupt  entry  binding,  and  operations  on  pointers 
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•  Sitfety-criti  trusted  requirements.  Ability  to  analyze  generated  code  for 
certificatioi.  and  to  provide  correspondence  between  the  source  and  the 
generated  code 

•  Support  programming  paradigms.  Subprogram  manipulation,  data  storage 
control,  recompilation,  object-oriented  programming  support,  and  generic 
modifications 

•  Parallel  or  distributed  processing  (capability  curremfy  does  not  east).  Distribution 
of  single  programs,  distribution  of  an  Ada  system,  remote  communications,  and 
configuration  control 

•  Information  systems.  Currency  quantity  handling,  character  set  compatibility, 
interface  to  Database  Management  Systems  (DBMSs),  and  common  data 
structures 

•  Scientific  and  mathematical  explications.  Location  of  point  and  data  storage 

•  International  user  requirements.  Topics  such  as  international  character  sets. 
7.1.U  Revision  Activities 

The  requirements  have  been  mapped  (1991-1992)  into  language  solutions,  and  the 
wording  in  the  standard  will  be  revised  by  September  1993.  Three  major 
enhancements  include  support  for  object-oriented  programming,  programming-in- 
the-large,  and  lightweight  synchronization. 

7.L2  Ada  9X  Transition  Activities 

Transition  activities  involve  management,  programmers,  vendors,  and  Ada  Conq)iler 
Validation  Capability  (ACVC)  test  suite  revision  and  policy. 

7.1.2.1  Managers 

To  help  managers  transition  to  Ada  9X,  two  Ada  9X  workshops  for  managers  will 
be  conducted  before  the  formal  standard  approval— one  for  mid-level  management 
and  one  for  executive-level  management  Transition  issues  and  strategies  will  be 
discussed. 

A  short  (approximately  IS-  to  20-minute)  videotape  that  discusses  the  language  in 
terms  of  corporate  benefits  and  poli^  issues  will  be  developed  for  managers  and  a 
concise  guide  to  practical  steps  for  transitioning  to  Ada  9X  from  both  non-Ada  and 
Ada  83-oriented  organizations  will  be  developed.  The  guide  will  be  similar  to  the 
Ada  Adoption  Handbook  for  Ada  83  developed  by  SEl.  It  will  include  a  discussion 
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of  the  benefits  of  using  Ada  9X  from  a  manager’s  per^ctive,  tips  on  tool  selection, 
and  a  summaiy  of  poUqr. 

1A22  Programmers 

To  help  Ada  83  programmers  transition  to  Ada  9X  vnAda  9X  Programmo’i  Guide 
will  be  developed.  This  guide  will  highlight,  chapter  by  chapter,  the  changes  between 
Ada  9X  and  Ada  83  and  discuss  programming  strategies  that  use  new  features.  Any 
incompatibilities  between  Ada  9X  and  Ada  83  will  also  be  noted,  and  straightforward 
modifications  to  Ada  83  code  will  be  provided  to  transition  to  equivalent  Ada  9X 
code.  Suggested  Ada  83  coding  practices  to  facilitate  the  transition  to  Ada  9X  also 
will  be  disctissfd  for  those  programmers  who  are  continuing  to  use  Ada  83  on 
evicting  projects.  A  1-hour  videotape  also  will  be  developed  that  will  highlight  the 
rhafig<.s  to  the  language  and  will  feature  opportunities  for  use  as  well  as 
programming  examples. 

7.1.2J  Vendors 

During  the  Ada  9X  revision  process,  several  workshops  for  vendors  will  be 
The  purpose  of  these  workshops  will  be  to  allow  vendors  to  closely  track 
the  revision  to  provide  feedback  on  implementabiliQ^  to  Ada  9X  teams.  An 
electronic  vendor  bulletin  board  has  been  established  to  allow  vendors  to  interact 
directly  with  Ada  9X  Project  team  members.  Open  and  direct  dialogue  is  essential 
for  a  timefy  and  effective  transition. 

7 A2A  ACVC  Test  Suite  Revision 

AJPO  has  frozen  the  Ada  83  test  suite  (ACVC  1.11).  For  information  only,  a 
baseline  for  the  Ada  9X  ACVC  Test  Suite,  9XBasic,  will  be  released  approximately 
12  months  before  ANSI  approval.  It  will  eliminate  incompatibilities  between  Ada 
83  and  Ada  9X  and  focus  on  usage-oriented  tasks  rather  than  remote  fringes  of  the 
language. 

The  first  Ada  9X  ACVC  release  will  be  designated  ACVC  2.0  and  will  cover  part  of 
the  new  Ada  9X  features.  The  Ada  9X  test  suite  will  focus  on  usage.  Table  7-1 
provides  the  planned  release  schedule. 
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OI(jectives 

Tests 

Certificate 

Suite 

Available 

Avidlable 

Start 

End 

Expiration 

2.0 

2  MAC 

3MA9X 

3MA9X 

27MA9X 

36MA9X 

2.1 

3MA9X 

9MA9X 

27MA9X 

63MA9X 

75  MA9X 

MAC  «  Months  after  release  of  Ada  9X  ANSI  canvass  for  voting 
MA9X  »  Months  after  ANSI  approval  of  Ada  9X 

Table  7<1.  ACVC  Planned  Release  Schedule 


12  Ada  REUSE 

Several  efforts  (e.g.,  STARS,  CIM,  SWAP)  are  under  way  to  address  software  reuse. 
The  Department  of  Defense  (DOD)  and  other  agencies  (e.g.,  the  Joint  Integrated 
Avionics  Working  Group  [JIAWG],  National  Aeronautics  and  Space  Administration 
[NASA])  recognize  that  software  reuse  has  the  potential  to  yield  substantial 
improvements  in  the  quality  and  reliability  of  DOD  software  systems  at  a  reduced 
cost  The  main  objective  of  all  of  these  efforts  is  to  create  an  environment  in  which 
Program  Managers  can  reuse  already  developed  software  components  rather  than 
develop  new  code.  The  reuse  concept  however,  raises  several  issues  that  must  be 
addressed  and  resolved,  including  the  following: 

•  Polity  and  regulations  that  inhibit  software  reuse 

•  Incentives  to  developers.  Program  Managers,  and  contractors  to  reuse  existing 
software 

•  DOD  infrastructure  to  facilitate  widespread  software  reuse 

•  Cultural  change  in  the  areas  of  software  development  acquisition,  and  support 
to  accept  and  promote  reuse 

•  Legal  and  contractual  issues 

•  Work  force  education  in  areas  of  reuse  technology 

•  Technology  to  support  confident  composition  of  software  components 

•  Limited  tool  support. 
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13  CORPOIUTE  INFORMATION  MANAGEMENT 

QM  is  the  initiative  through  which  DOD  will  integrate  and  strengthen  central 
management  of  the  Defense  Information  Management  Program.  The  goal  of  the 
QM  initiative  is  to  improve  the  effectiveness  and  efficiency  of  business  processes  in 
DOD  by  integrating  and  streamlining  fanctionai  requirements  and  by  using 
information  technology  to  implement  the  improved  business  operations  that  result 

The  Secretary  of  Defense  assigned  to  the  Office  of  the  Assistant  Secretary  of 
Defense  (OASD[C3I])  the  responsibility  for  establishing  an  organization  to 
implement  QM  t^ou^out  DOD.  Pursuant  to  this  direction  and  in  accordance  with 
the  "Plan  for  Implementation  of  Corporate  Information  Management  in  DOD," 
approved  by  the  Deputy  Secretary  on  14  January  OASD(C3I)  established  a 
Directorate  of  Defense  Information  (DDI),  which  is  responsible  for  the  following: 

*  Developing  and  promulgating  information  management  policies 

*  Implementing  information  management  processes,  programs,  and  standards 

*  Integrating  the  principles  of  information  management  into  all  of  DOD’s 
functional  activities. 

This  responsibility  applies  to  information  technologies  and  architectures,  software, 
systems  development  methods  and  tools,  information  technology  and  data  standards, 
and  Automatic  Data  Processing  (ADP)  equipment  acquisition  processes.  It  does  not 
include  equipment  and  software  that  are  an  integral  part  of  a  weapon  or  weapons 
^tem  and  related  test  equipment 

Application  of  QM  principles  will  enable  managers  of  functional  activities  to 
streamline  business  methods  and  business  processes,  develop  sound  business  cases 
and  functional  economic  analyses  of  their  activities  and  supporting  information 
technology,  and  provide  other  improvements  in  the  effectiveness  and  efficiency  of  the 
functional  activities.  The  OASD(C3I)  DDI  will  develop  and  promulgate  guidance 
on  the  common  models,  tools,  and  methodologies  to  be  used  by  functional  persoimel 
in  performing  their  responsibilities  for  the  management  of  information  related  to 
their  functions.  QM  also  supports  the  goals  of  the  July  1989  Defense  Management 
Report  to  the  President. 

7.4  INTEGRATED  COMPUTER-AIDED  SOFTWARE  ENGINEERING  TOOLS 
The  Department  of  Defense  (DOD)  is  committed  to  establishing  a  single,  common 
Software  Engineering  Environment  (SEE)  for  the  development  of  Automated 
Information  Systems  (AISs)."  This  dramatic  statement  introduces  a  far-reaching 
policy  memo,  the  DOD  I-CASE  Use  Polity,  signed  by  the  Director  of  Defense 
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Infonnation  on  27  February  1992.  With  the  establishment  of  the  1-CASE  policy, 
which  will  be  enabled  by  the  complementary  I-CASE  acquisition  program,  DOD  has 
made  a  major  strategic  commitment  to  apply  Computer-Aided  Software  Engineering 
(CASE)  technology  throughout  the  largest  software  development  organization  in  the 
world,  the  U.S.  DOD. 

The  I-CASE  policy  will  ultimately  result  in  the  modernization  and  standardization 
of  DOD’s  numerous  software  development  activities.  The  I-CASE  Use  Policy  memo 
states,  Tt  is  DOD  policy  that  I-CASE  will  be  used  by  each  Military  Department  and 
Defense  Agency  for  aU  in-house.  Government-developed  AISs."  For  contractor- 
developed  systems,  the  policy  requires  that  AIS  contracts  include  provisions  for 
delivering  computer  products  in  a  form  that  can  be  input  into  an  I-CASE  SEE. 
Preliminary  results  of  a  recent  survey  of  selected  DOD  software  development 
activities  indicate  that  DOD  owns  at  least  one  copy  of  virtually  every  commercial 
CASE  tool  in  the  marketplace.  Standardizing  on  I-CASE  will  reduce  the 
proliferation  of  incompatible  products  the  Department  must  support. 

To  implement  the  I-CASE  policy,  the  U.S.  Air  Force  has  been  designated  as  the 
Executive  Agent  for  I-CASE  and  charged  with  identifying  DOD  CASE  requirements 
and  establishing  an  acquisition  program  to  meet  those  requirements.  The  Air  Force 
has  created  the  I-CASE  System  Programming  Office  (SPO)  at  Maxwell  AFB,  Gunter 
Armex,  Alabama,  to  manage  the  acquisition.  The  mission  of  the  I-CASE  SPO  is  to 
bring  I-CASE  to  fruition  as  soon  as  possible  so  that  users  throughout  .DOD  will  have 
a  standard  SEE  and  associated  hardware,  training,  and  technical  support  services. 
The  I-CASE  contract,  which  is  expected  to  be  awarded  in  late  1993,  will  be  available 
throughout  DOD  and  to  other  Federal  agencies. 

The  I-CASE  acquisition  will  provide  DOD  software  development  and  maintenance 
organizations  with  the  latest  SEE.  I-CASE  will  com'st  primarily  of  Commerdal-Off- 
Tbe-Shelf  (COTS)  hardware  and  software  development  components  and  the 
necessary  run-time  licenses  to  execute  the  systems  developed  in  the  environment. 
The  use  of  COTS  tools  in  the  I-CASE  enviromnent  will  be  strongly  emphasized. 
I-CASE  will  include  a  central  repository  for  storing  all  information  relating  to  a 
specific  software  project  and  will  support  a  full  range  of  program  development  tools 
that  covers  each  phase  of  the  software  life  Qrcle.  Additionally,  I-CASE  will  support 
common  management  functions  extending  across  multiple  life-cycle  phases  such  as 
program  management,  Quality  Assurance  (QA),  and  configuration  management. 

Figure  7-1  illustrates  the  I-CASE  technical  environment. 

DOD  is  moving  rapidly  to  establish  a  standards-based  computing  environment  and 
has  identified  several  standards  that  will  be  mandatory.  I-CASE  must  operate  under 
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these  standards  and  will,  in  turn,  be  used  to  develop  implications  that  execute  on 
open  ^ems  platforms.  The  I-CASE  environment  will  support  or  meet  the  following 
standards: 

•  Portable  Common  Tool  Environment  (PCTE)  to  provide  a  standard  repository 
interface  through  the  PCTE  specification 

•  Ada  to  generate  code  in  Ada,  the  DOD  standard  High  Order  Language  (HOL) 

•  Structured  Query  Language  (SQL)  to  support  an  SQL  interface  to  at  least  two 
Relational  Database  Management  Systems  (RDMSs) 

•  XWindows  to  support  XWindows  for  end-user  applications 

•  Portable  Operating  System  Interface  for  Computer  Systems  (POSIX)  to  support 
applications  executing  in  a  POSIX  operating  environment 

•  GovemmetU  Open  Systems  Intarcormarthn  Profile  (GOSIP)  to  provide  support 
for  GOSIP. 

The  I-CASE  environment  will  also  comply  with  i.\c  National  Institute  of  Standards 
and  Technology  (NIST)/European  Computer  Manufacturing  Association  (ECMA) 
Reference  Model  for  Frameworks  of  Software  Engfneerir^  Environments. 

Public  Law  102-396,  Section  9070,  requires  that  DOD  use  the  Ada  programming 
language  for  all  applications  except  where  is  it  cost-effective  not  to  do  so. 
Consequently,  Ada  has  been  specified  as  the  only  third-generation  language  that  will 
be  supported  by  the  I-CASE  environment  Initially,  I-CASE  will  support  Ada  83,  but 
when  the  Ada  9X  requirements  are  approved,  I-CASE  will  evolve  to  the  new  version. 
At  a  minimum,  the  I-CASE  environment  will  generate  Ada  program  unit  skeletons 
and  the  user  will  be  required  to  complete  the  functionality.  By  the  end  of  the  7-year 
contract  however,  we  expect  I-CASE  to  generate  100%  of  the  code  required  for  an 
appUcatioa 

The  I-CASE  environment  will  strongly  emphasize  the  integration  of  all  supported 
software  development  tools  across  each  possible  dimension  of  integration  (i.e., 
controt  presentation,  data,  and  process).  I-CASE  will  support  at  least  one,  but 
preferably  more,  of  the  most  widely  accepted  software  development  methodologies. 
DOD  ^tems  today  are  developed  by  using  a  wide  variety  of  methodologies  ranging 
from  fiinctional  and  data-driven  approaches  to  state  transition  and  object-oriented 
methodologies.  Support  is  needed  for  as  many  of  these  as  possible;  however,  the 
emphasis  is  on  the  requirement  for  an  object-oriented  methodology.  Process  and 


Ada  Implamantation  GuWa 


87 


Futura  DhacUont 


work  flow  control  of  the  tools  in  the  environment  will  be  an  important  feature  of 
I-CASE,  and  groupware  support  is  expected  to  be  part  of  any  development  process. 

In  addition  to  providing  the  traditional  functions  offered  by  a  SEE,  I-CASE  will 
strongly  emphasize  reuse  of  previously  developed  software  components.  Within 
l-CASI^  the  reusability  of  all  software  objects  in  the  repositoiy  be  supported, 
from  requirements  through  design  to  code  construction  and  eventually  to  testing. 
Each  I-CASE  environment  will  be  connected  to  the  DOD  Software  Repositoiy 
System  (DSRS),  a  multidomain  software  reuse  library.  Each  I-CASE  environment 
will  also  be  connected  to  the  DOD  Data  Repositoiy  System  (DDRS),  which  will 
provide  access  to  common  data  elements,  data  definitions,  and  data  models  used 
across  DOD.  Software  metrics,  an  integral  part  of  the  SEE,  will  capture  DOD- 
specific  metrics  at  each  phase  of  the  software  life  ^cle. 

The  execution  of  the  I-CASE  contract  will  break  new  ground  for  a  DOD  acquisition. 
DOD  recognizes  the  state  of  technology  of  SEEs  is  evolving  rapidly  and  the  I-CASE 
contract  must  be  innovative  in  its  approach  to  technology  e^ancements  and 
upgrades.  To  ensure  that  DOD  always  has  current  SEE  technology,  broad 
requirements  have  been  set  for  the  initial  I-CASE  deliveiy.  Each  requirement  in  the 
Request  for  Proposals  (RFP)  has  been  demonstrated  in  one  or  more 
implementations;  however,  the  total  of  all  requirements  effectively  advances  the 
state  of  the  art  Consequently,  I-CASE  is  structured  into  tiered  requirements,  with 
the  mandatoiy  requirements  at  contract  award  representing  only  a  subset  of  the  long¬ 
term  need.  At  award  time,  the  I-CASE  contractor  will  deliver  all  mandatory 
requirements,  a  subset  (large,  it  is  hoped)  of  the  I-CASE  "tiered”  requirements,  and 
a  "migration  plan"  for  incoiporating  requirements  that  were  not  part  of  the  initial 
deliveiy.  A  substantial  award  fee  should  encourage  adherence  to  the  migration  plan. 

The  contract  will  require  commercialization  of  the  I-CASE  environment  Therefore, 
in  addition  to  providing  the  I-CASE  SEE  to  DOD  and  other  Government  agencies, 
the  winning  contractor  must  also  sell  the  environment  commercially.  Moreover,  it 
is  a  DOD  goal  to  make  the  information  repositoiy  data  model  and  interface 
specification  open  and  public  information.  DOD  anticipates  that  many  third-party 
suppliers  of  CASE  tools  will  adapt  and  integrate  their  products  to  the  I-CASE  SEE. 
DOD  has  long  been  the  recipient  of  Government-only  technology  that  frequently 
s^roaches  obsolescence  on  the  day  it  is  delivered.  Hie  I-CASE  contract  intends  to 
"ride  the  wave”  of  commercial  SEE  development  and  thus  ensure  that  DOD  software 
developers  are  provided  with  the  latest  technology  to  support  the  DOD 
"customer"— the  soldier,  sailor,  and  aviator  of  the  U.S.  armed  forces. 
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NEXT  GENERATION  COMPUTER  RESOURCES 
The  Next  Generation  Computer  Resources  (NGCR)  Program  is  providing  Navy  air, 
surface,  and  subsurface  tactical  systems  Program  Managers  and  system  developers 
with  computer  hardware  and  softvme  interface  standards  that  will  allow  the  Navy  tu 
transition  to  commercially  based  open  ^tems  designs.  Open  ^tems  designs  will 
reduce  Navy  dependence  on  the  original  ^tem  suppliers  by  allowing  competition  for 
procurement  and  modification/upgrades  to  Navy  mission  critical  systems. 

To  achieve  program  objectives,  the  NGCR  program  has  established  working  groups 
in  critical  computer  standardkation  areas  including  backplane  busses,  networl^ 
operating  ^tems,  database  management  systems,  graphics,  and  project  support 
environments,  'l^ese  working  groups  are  composed  of  NGCR-funded  Navy 
personnel  with  voluntary  participation  from  industry.  The  task  of  each  group  is  to 
work  direct’^'  with  nationsd  and  international  standards  organizations  to  infuse  Navy 
requiremer.  r.  into  the  commercial  standards.  When  successful,  this  allows  the  Navy 
to  leverage  commercial  investments  by  using  the  resulting  open  commercial  standard 
in  its  weapons  systems.  This  modular  approach  to  systems  design  will  allow 
technology  to  evolve  in  a  competitive  environment  and  without  revolutionary  changes 
in  the  systems  architecture. 

The  NGCR  effort  is  fostering  an  Open  Systems  Architecture  (OSA)  aj^roach  to 
computer  resource  acquisition.  For  OSAs,  the  internal  and  external  hardware  and 
software  interfaces,  services,  and  protocols  are  well  specified;  they  have  undergone 
public  review  and  have  been  published  and  widely  accepted  as  standards  by 
organizations  such  as  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE), 
ANSI,  and  ISO;  and  they  are  implemented  in  vendor  products.  This  approach  will 
allow  the  Navy  to  take  advantage  of  existing  and  future  industrial  competition  and 
innovation  on  a  continuing  basis,  which  will  dramatically  improve  the  technical  and 
operational  performance  of  DON  computer-based  ^sterns. 

The  NGCR  Program  is  pursuing  standards  in  the  following  areas  (note  that  the  dates 
provided  indicate  the  planned  availability  of  the  completed  standards): 

•  Local  Area  Network  (LAN)— Survivable  Adaptable  Fiber-optic  Embedded 
Network  (SAFENET)*,  October  1992 

•  Backplane  (BP)*-FUTUREBUS+,  June  1993 

•  Operating  System  Interface— POSIX,  December  1995 

•  High  Performance  Network,  September  1996 
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•  High-Speed  Data  Transfer  Network,  September  1996 

•  DBMS  Interface,  September  1998 

•  Graqphics  Language  Interface,  September  1998 

•  High  Performance  Backplane  (HPBPX  TBD 

•  PSE,  suspended. 

Of  the  areas,  only  the  BP  and  the  LANs  (ie.,  items  marked  with  an  asterisk) 
will  be  actually  prototyped  and  conformance  t^ted  as  part  of  the  NGCR  prograiiL 
A  formal  mnfnrmatige  testing  durability  will  be  established  within  DON  arid  be 
available  for  acquisition  managers  by  199S.  Tbe  program  is  encouraging  industry  to 
undertake  initiatives  in  this  area  so  as  to  transition  all  testing  away  from  the  Navy. 

75.1  Project  Support  Environmoit  Standards  Working  Group 
Consistent  with  the  objectives  of  the  overall  NGCR  program,  the  goal  of  the  Project 
Support  Envirorunent  Standards  Working  Group  (PSESWG)  is  to  establish  DON 
standards  for  PSE  interfaces  that  will  enhance  the  DON*s  ability  to  acquire  PSEs 
quidcty  and  cost-effectivety.  Also  consistent  with  the  NGCR  program  guidance,  the 
PSESWG  is  a  joint  team  cotrqxrsed  of  menibeTS  from  DON,  other  Government 
organizations,  industry,  and  academia. 

PSE  interfaces  selected  for  standardization  will  include  data  interdhange  formats  and 
interfaces  to  the  user,  a  DBMS,  life-^de  process  management,  and  a  network. 
Because  the  objective  is  to  standardize  interfaces  based  on  industry  standards,  the 
PSESWG  work  will  not  selea  particular  tools  or  products.  Tire  groiq>  is  pursuing  the 
adqrtion  of  interfaces  with  Ada  language  bindings  as  well  as  those  for  other 
languages,  such  as  C 

Tbe  PSESWG  coordinates  with  several  other  important  groups  in  the  enviromnents 
community,  including  SEI,  STARS,  ami  NIST,  in  addition  to  the  other  military 
Smvices.  This  coordination  is  expected  to  yidd  tire  maxirmim  benefit  and  reduce 
diqrlication  of  effort  Because  of  the  wide  range  of  interfaces  to  be  considered  for 
standardization  by  PSESWG,  the  standards  are  e]q>ected  to  emerge  inaementaUy, . 
perhaps  as  early  as  1994.  AlAough  the  original  pli^  called  for  continuing  the  work 
until  approxiniatefy  1998,  the  NGCR  funding  situation  will  not  allow  the  work  to 
contirme  beyond  1^93.  The  products  of  the  PSESWG  to  date,  most  notabfy  the 
Next  Generation  Computer  Resources  (NGCR)  Reference  Model  for  Project 
Siqrport  Environments,  Version  2.0, 2  September  1993,  will  crmtinue  to  be  available 
as  the  basis  for  launching  future  work. 
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1S2  Operating  Systems  Standards  Woridng  Group 

The  Navy’s  NGCR  program  and  NASA  have  selected  the  POSIX  IEEE  1003 
standard  as  the  nonproprietaiy  operating  ^tem  interface  standard.  The  NGCR 
Operating  Systems  Standards  Working  Group  (OSSWG)  is  participating  in  the  IEEE 
POSIX  group  to  influence  the  standards  so  that  they  will  support  Navy  requirements. 
POSIX  areas  of  standardization  of  particular  interest  to  the  NGCR  program  include 
real'time  extensions,  Ada  bindings,  security  extensions,  and  distributed  computing 
standardization  features. 

7.6  NORTH  AMERICAN  PORTABLE  COMMON  TOOL  ENVIRONMENT 
INITIATIVE 

The  North  American  Portable  Common  Tool  Environment  Initiative  (NAPI),  a  joint 
technical  initiative  among  Government,  industry,  and  academia,  was  created  to 
provide  a  forum  to  represent  North  American  interests  in  PCTE  and  to  foster  the 
establishment  of  a  market  for  the  growth  of  PCTE  tools  and  environments. 

7.6.1  Background 

During  the  past  decade,  the  software  development  community  has  become 
increasingly  aware  of  the  need  for  integrated  tools  that  share  data  and  systems  that 
allow  tools  to  interoperate.  The  full  power  of  CASE  tools  can  only  be  realized  when 
these  tools  are  integrated  into  a  common,  distributed  SEE.  Such  an  environment  will 
consist  of  a  framework  of  common  operations  that  provide  basic  integration  facilities 
based  upon  an  open  common  repository  with  additional  support  for  communication, 
user  interface,  and  process  support  functionality. 

An  integrated  environment  will  provide  a  platform  to  facilitate  addition  of  new  tools 
to  improve  user  productivity  and  software  quality.  It  will  benefit  both  tool  developers 
and  users.  From  the  tool  developer’s  perspective,  a  single  set  of  integration 
standards  will  enable  development  of  lower-cost  and  higher-quality  products  across 
multiple  hardware  platforms.  From  the  user’s  point  of  view,  the  existence  of 
standards  will  mean  that  the  same  type  of  products  will  be  available  fi’om  several 
sources,  which  will  give  the  user  a  broader  selection  and,  because  of  vendor 
competition,  possibly  reduce  acquisition  and  maintenance  costs.  Sudi  interfaces 
should  support  the  needs  of  both  the  defense  and  non-defense  communities. 

Among  the  candidates  suggested  for  such  a  data  interface  have  been  the  Common 
Ada  Programming  Support  Environment  (Ada  PSE)  Interface  Set  (CAIS-A), 
developed  under  the  sponsorship  of  the  AJPO  (MIL-STD-ISSSA);  A  Tool  Integration 
Standard  (AUS),  currently  under  consideration  by  ANSI  working  group  X3H6;  and 
the  PCTE,  developed  under  the  aegis  of  ECMA  (ECMA-149).  Each  of  these 
provides  a  set  of  basic  services  for  other  software  tools,  and  each  of  these  sets  of 
services  (in  different  ways)  supplies  some  of  the  capabilities  of  a  "framework." 
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Focus  on  PCTE  _ 

NAPI  will  focus  on  PCTE  as  a  baseline  standard  because  PCTE  is  now  the  leading 
internationally  recognized  interface  standard  that  appears  to  meet  a  reasonable  set 
of  firamework  repository  requirements.  PCTE  does  not  currently  provide  all  of  the 
functionality  that  the  software  development  community  needs;  however,  it  can  evolve 
toward  the  needed  functionality  and  NAPI  can  influence  PCTE’s  evolution  in  an 
open  process.  ECMA  and  its  Technical  Committee  33  (TC33)  oum  the  standard; 
however,  ECMA  is  planning  to  submit  it  to  the  Joint  Technical  Committee  1  (JTCl) 
in  mid-1993  for  adoption  as  an  ISO  standard.  ECMA’s  ownership,  and  eventually 
ISO’s  ownership,  of  the  standard  means  that  this  is  a  publicly  available, 
nonproprietary  standard. 

Although  no  commercial  implementations  of  the  hill  standard  exist,  Emeraude, 
Verilog,  and  Heuristix  Systems  have  implemented  a  forerunner  of  the  standard 
(PCTE  1.5).  These  companies,  as  well  as  IBM,  Digital  Equipment  Corporation,  ISSI, 
and  EDS  Scion,  have  announced  they  are  implementing  the  full  standard,  but  no 
company  has  provided  a  firm  product  release  date. 

Because  PCTE  is  a  technology  of  considerable  importance  to  both  government  and 
industry  in  North  America,  NIST,  DOD,  and  the  Object  Management  Group  (OMG) 
have  jointly  proposed  the  creation  of  NAPI  with  U.S.  industry  taking  a  leading  role. 
NAPI  will  provide  a  forum  for  North  American  interest  in  PCTE,  and  give  North 
America  a  voice  to  express  opinions  to  TC33,  ECMA,  and  ISO  on  the  future 
development,  evolution,  and  adoption  of  the  standard  and  its  revisions.  NAPFs 
ultimate  goal  is  a  good  interface  for  ISEE  technology;  the  baseline  NAPI  has  chosen 
to  begin  working  toward  this  goal  is  PCTE. 

Industry  and  government  in  North  America  will  collaborate  in  NAPI  to  lormalize 
North  American  interest  in  PCTE  and  to  work  toward  the  achievement  of  a  widely 
used  common  software  tool  interface.  NAPI  will  work  with  other  groups  that  support 
PCTE,  specifically  the  North  American  PCTE  Users’  Group  (NAPUG)  and  the 
PCTE  Interface  Management  Board  (PIMB).  NAPI  will  not  compete  with  any 
vendors  but  will  provide  benefits  to  tool  and  repository  vendors  by  stimulating 
demand  for  PCTE-compliant  products. 

7.^  Goals  for  NAPI 
NAPI  has  five  primary  goals: 

•  To  promote  the  use  of  the  PCTE  spec^cation  as  the  definition  of  a  set  of  services 
for  ISEEs.  NAPI  will  create  a  forum  for  discussing  PCTE;  provide  newsletters 
and  electronic  bulletin  boards;  and  invite  framework  vendors,  tool  developers, 
and  end  users  to  various  tymposia,  workshops,  and  meetings.  These  activities 
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will  mform  the  North  Americ.'i  market  about  the  use,  implementation,  and 
evolution  of  PCTE  and  the  wsnefits  of  using  or  developing  PCTE-based 
products. 

•  To  provide  a  recognized  fonun  in  North  America  far  the  maintenance  and 
evolution  of  the  PCTE  standard,  with  the  goal  of  booming  the  United  States 
Technical  Advisory  Group  (USTAG)  for  PCTE.  This  forum  will  develop  goals 
for  modifying  or  extending  PCTE  ami  will  examine  ways  to  develop  PCTC  to 
achieve  those  goals  by  working  with  TC33,  PIMB,  ISO,  and  other  organizations. 
Sudi  extensions  would  include  support  for  fine-grained  data,  trusted  systems, 
and  object-oriented  methods.  NAPl  will  also  include  discussions  of  ISO 
standardization  with  members  of  ECMA  and  will  support  adoption  of  PCTE 
as  a  standard  in  the  United  States. 

•  To  tiaise  wUh  other  organizations  to  encourage  the  developmera  of  additional 
fiwnework  services  require  or  useful  for  SEEs  compatible  with  PCTE.  An 
integrated  SEE  will  need  additional  framework  services  beyond  those  ECMA- 
149  currently  specifies  in  PCTE.  Incorporating  additioiud  services  or  modifying 
PCTE  to  ensure  compatibilify  and  efficient  execution  with  such  interfaces  or 
standards  is  a  goal  of  NAPI  members.  Possible  candidate  services  for  inclusion 
into  an  integrated  SEE  framework  are  as  follows: 

-  '  Services  for  communication,  such  as  OMG’s  Common  Object  Request 

Broker  Architecture  (CORBA)  or  Hewlett-Padcard’s  (HFs)  Broadcast 
Message  Server  (BMS) 

-  Additional  data  services  sudi  as  those  provided  by  ATIS  or  X3H4 
(Information  Resource  Directory  System  [IRDS]) 

Services  for  Graphical  User  Interfaces  (GUIs)  such  as  the  Massachusetts 
Institute  of  Technology  consortium’s  XWindow  System 

-  Services  for  process  management  activities. 

•  To  encourage  development  of  usefid  integration  amventions  (Le.,  schemas, 
conventions,  protocols)  for  integrated  SEEs.  Providing  a  common  repository  is 
not  sufficient  for  tools  to  share  data.  The  semantics  of  the  shared  data  must 
be  agreed  to  in  advance,  and  common  notations  and  conventions  must  be 
established  for  sharing  such  information. 

•  To  encourage  the  development  of  a  market  for  PCTE  tools  and  environments. 
Industry  and  goverrunent  commitments  to  purchase  PCTE  products  will 
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stimulate  investment  in  the  development  of  such  products  by  demonstrating  to 
developers  that  a  market  exists  for  PCTE  products. 

To  achieve  these  goals,  NAPI  will  undertake  the  following  tasks  in  the  near  term. 

•  Encourage  all  members  of  the  PCTE  community  to  participate  in  evolving  the 
PCTE  standard  to  meet  current  and  future  needs  of  the  software  development 
community. 

•  Ensure  similarity  of  PCTE  implementations  by  encouraging  the  development 
of  a  conformance  test  suite.  The  proposed  model  for  this  process  is  similar  to 
the  POSIX  product  validation  process.  After  the  test  suite  has  been  developed, 
NAPI,  through  NIST,  could  certify  various  laboratories  in  North  America  and 
possibly  in  Europe  to  perform  official  testing  to  certify  products  as  compliant 
with  PCTE.  The  validation  and  test  suite  would  be  publicly  available,  however, 
for  use  by  vendors  and  developers  in  performing  their  own  in-house  unofficial 
testing. 

•  Develop  clear  definitions  of  the  relationship  between  PCTE  and  other 
framework  services.  Use  of  the  NIST/ECMA  framework  r^sierence  model 
provides  a  basis  and  a  consistent  notation  for  describing  framework  services 
such  as  those  provided  by  PCTE  and  other  related  standards. 

•  Promote  the  use  and  analysis  of  PCTE  in  universities  and  research  institutions. 
Universities  are  a  primary  source  of  programmer  expertise  in  such  technology 
and  for  understanding  and  developing  extensions  to  the  standard. 

7.6.4  NAPFs  Organization 

All  NAPI  contributing  participants  from  government,  industry,  and  academia  will  be 
partners  with  a  shared  strategy  and  a  shared  set  of  technical  objectives  decided  by 
a  consensus  process.  The  strengths  each  organization  brings  to  the  initiative  will 
shape  its  role  in  the  initiative. 

NAPI  will  consist  of  an  executive  committee  of  active  contributors  drawn  from  the 
PCTE  community  and  four  tedinical  committees.  The  NAPI  membership  will 
determine  the  future  direction  and  goals  of  NAPI;  however,  NAPI  will  be  interested 
in  listening  to  aity  comments  on  how  PCTE  should  evolve. 

The  four  technical  committees  and  their  roles  are  as  follows: 

•  Technical  Committee  1  (TCI)  will  focus  on  maintenance  and  evolution  of  the 
PCTE  standard  and  will  examine  ways  to  develop  the  PCTE  standard  to  meet 
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the  ISEE  needs  of  the  sonware  development  community.  All  interested 
members  of  the  PCTE  community  will  be  encouraged  to  contribute  to  TCI 
because  standards  evolution  should  be  an  open,  consensus-driven  process.  TCI 
will  make  recommendations  to  the  steering  committee,  whi<±  will  make 
recommendations  to  TC33,  ECMA,  ISO,  and  other  standards  organizations. 
These  recommendations  will  represent  the  North  American  consensus  position 
on  the  direction  PCTE  should  take. 

•  Technical  Committee  2  (TC2)  will  be  responsible  for  development  of  the 
validation  and  testing  teclmology,  induding  defining  the  scope  of  the  test  suite 
and  interim  goals  for  production  of  the  test  suite  and  directing  work  in  this 
area.  The  test  suite  will  be  publidy  available.  TC2  will  work  with  DOD  and 
other  government  and  industry  contributors  to  fashion  a  test  suite  suitable  for 
compliance  testing  of  PCTE.  TC2  will  also  work  with  the  European 
Commission’s  PCTE  test  suite  contractor  so  that  the  two  test  suites  will  be 
complementary.  NIST  will  establish  the  mechanisms  for  joint  development  of 
the  validation  and  test  suite  and  will  use  the  development  of  the  POSIX  test 
suite  as  a  model.  Technical  contributions,  such  as  PCTE  vendor’s  in-house 
testing  technology,  could  be  made  available  to  NAPl  under  Cooperative 
Research  and  Development  Agreements  (CRADAs)  with  NIST.  These 
agreements  would  protect  vendor  ownership  unless  that  code  became  part  of 
the  adopted  validation  and  test  suite,  at  which  time  vendors  would  have  to  give 
up  such  ownership. 

•  Technical  Committee  3  (TC3)  will  promote  the  use  and  analysis  of  PCTE  in 
universities.  As  a  means  of  achieving  its  goals  of  promoting  and  evolving 
PCTE,  NAPI  supports  the  acquisition  and  analysis  of  PCTE  by  universities. 
The  active  use  of  PCTE  at  universities  means  that  more  students  will  get 
experience  with  PCTE,  and  more  research  in  extending  the  standard  will  occur. 

•  Technical  Committee  4  (TC4)  will  develop  clear  definitions  of  Jhe  relationship 
between  PCTE  and  other  SEE  framework  services  to  promote  better 
integration  among  SEE  products.  TC4  will  provide  a  forum  for  those 
interested  in  discussing  integration  issues  and  recommending  interfaces 
between  PCTE  and  other  SEE  products. 

The  first  two  committees  are  the  initial  NAPI  technical  committees.  The  second  two 
are  proposed  additional  committees  to  address  other  NAPI  goals.  All  of  NAPI’s 
major  activities  will  be  joint  undertakings  by  government,  industry,  and  academia. 
One  major  role  for  the  U.S.  Federal  Government  will  be  to  provide  core  funding, 
and  a  major  role  for  industry  will  be  to  provide  technical  expertise.  Therefore,  no 
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NAPI-spODSored  projects  will  be  "goveminent*only”  projects,  nor  will  they  be 
proprietary  and  commercial. 

7,63  Bendits  of  the  Initiative 

The  initiative  will  benefit  all  potential  ISEE  developers  and  users:  government 
agencies,  vendors  of  software  environment  frameworks,  tool  developers,  and  tool 
users. 

The  U.S.  Federal  Government,  a  major  user  of  tools  and  environments,  benefits  from 
the  adoption  of  ISEE  technology,  and  PCTE  in  particular,  through  the  productivity 
by  greater  interoperability  of  tools  and  services.  NAPI  furthers  these 
objectives  by  providing  a  forum  for  government  agencies  and  other  customers  to 
discuss  their  needs  in  the  evolution  of  the  standard.  A  vahdation  and  testing 
tn*.rhn«icm  will  also  assuTe  PCTE  buyers  that  they  are  obtaining  a  version  of  PCTE 
that  complies  with  the  specifications.  Validating  PCTE  implementations  is  important 
to  that  expect  to  acquire  an  accurate  version  of  PCTE  and  have  stated 

procurement  goals  of  obtaining  PCTE. 

For  framework  vendors  who  are  implementing  PCTE,  NAPI  has  strategic  benefits. 
It  provides  a  legal  umbrella  for  exchange  of  technical  information.  Framework 
vendors  can  Hiiuniss  the  technical  problems  of  extending  PCTE  and  vahdating  the 
technology  and  can  hear  what  customers  are  looking  for  in  PCTE  products. 

NAPI  will  enable  framework  vendors  who  are  not  implementing  PCTE  to  keep 
informed  about  PCTE  and  discuss  compatibility  issues.  Other  framework  vendors 
need  to  know  what  PCIE’s  strengths  are  and  how  PCTE  compares  to  and  interfaces 
with  other  SEE  products. 

Participation  in  NAPI  will  allow  tool  developers  to  discuss  issues  in  ISEE  technology 
and  open  systems  and  the  way  PCTE  and  other  standard  services  should  evolve  to 
address  those  issues. 

NAPTs  use  of  PCTE  as  a  baseline  for  ISEE  tedmology  and  the  U.S.  Federal 
Government’s  support  for  PCTE  products  will  encourage  developers  to  create  more 
PCIE-compliant  products.  This  encouragement  will  increase  competition.  Several 
U.S.  Government  organizations  have  already  announced  that  they  intend  to  support 
PCTE.  For  example,  the  DOD’s  RFP  for  I*CASE  requires  that  the  final  version  of 
I-CASE  be  PCTE  compliant  As  PCTE  evolves,  the  number  of  mandates  for  the  use 
of  PCTE  in  U.S.  Federal  Government  procurements  will  increase. 
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7.7  PORTABLE  COMMON  INTERFACE  SET 

The  PQS  Program  is  a  North .  .tlantic  Treaty  Organization  (NATO)  effort  sponsored 
by  the  Special  Working  Group  on  Ada  Programming  Support  Environments  (SWG 
on  Ada  PSEs).  This  program  will  define  framework-level  services  for  an  ISEE. 
These  framework  services  will  be  based  on  requirements  identified  in  the 
International  Requirements  and  Design  Criteria  (IBAC)  document,  and  they  will 
reflect  the  ECMA/NIST  SEE  Frameworks  Reference  Model.  Services  in  the 
following  areas  will  be  considered: 

•  Object  management 

•  Process  management 

•  Communication 

•  User  interface  services. 

The  PQS  framework  interface  will  be  based  on  the  ECMA  PCTE  to  which  a 
standard  Ada  binding  exists  as  ECMA  Standard  162.  The  PQS  Program  will 
develop  the  framework  services  in  the  French  Entreprise  II  environment  Plans  are 
to  complete  the  PQS  framework  interface  definition  by  the  end  of  1993.  A 
prototype  and  Ada  PSE  demonstrator  are  planned  for  early  1994.  Production  quality 
environments  based  on  PQS  are  expected  by  the  end  of  1995. 

7.8  SOFTWARE  ENGINEERING  INSTITUTE 

The  SEI  is  a  federally  funded  research  and  development  center  sponsored  by  DOD 
through  the  Advanced  Research  Projects  Agency  (ARPA)  (formerly  DARPA).  The 
Air  Force  Systems  Command  (Electronic  Systems  Division)  awarded  the  SEI  contract 
to  Camegie-Mellon  University  (CMU)  in  December  1984.  In  December  1989,  the 
contract  was  renewed  for  another  S  years. 

The  SEI  mission  is  to  provide  leadership  in  advancing  the  state  of  the  practice  of 
software  engineering  and  to  improve  the  quality  of  systems  that  depend  on  software. 
The  SEI  expects  to  accomplish  its  mission  by  promoting  the  evolution  of  software 
engineering  from  an  ad  hoc,  labor-intensive  activity,  to  a  discipline  that  is  well 
managed  and  supported  by  technology.  The  SEI  carries  out  its  mission  by  offering 
products  and  services  that  help  SEI  customers  to  improve  the  quality  of  their 
software,  as  described  below. 

7.8.1  Software  Development  Process 

The  SEI  concentrates  on  improving  the  software  development  process.  In  projects 
related  to  process,  SEI  is  assessing  the  actual  practice  of  software  engineering  in  the 
defense  community,  is  training  organizations  to  gain  management  control  over  their 
software  development  processes,  and  is  supporting  the  use  of  quantitative  methods 
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for  software  process  management  Included  in  this  focus  area  are  the  following 
projects: 

•  The  Software  Process  Measurement  Project  advocates  the  use  of  measurement 
in  managing,  acquiring,  and  supporting  software  systems.  The  project  is 
formulating  relii^le  measures  of  the  software  development  process  and 
products  to  guide  and  evaluate  development  To  expedite  DOD  and  industiy 
transition,  the  project  is  actively  working  with  professionals  from  Government, 
industiy,  and  academia  to  encourage  organizations  to  use  quantitative  methods 
to  improve  their  software  processes. 

•  The  objectives  of  the  Software  Process  Definition  (SPD)  Project  are  to 
establish  as  standard  software  engineering  practice  the  use  of  defined  processes 
for  the  management  and  development  of  software  and  to  advance  the 
capabilities  required  to  define  the  software  process  within  an  organization. 
The  SPD  Project  supports  process  improvement  through  the  development  and 
maturation  of  methods  and  technology  that  support  process  definition. 

•  The  Capability  Maturity  Model  (CMM)  Project  maintains  a  model  describing 
how  organizations  can  improve  their  software  process  maturity.  This  model 
will  be  continuously  updated  as  the  state  of  the  art  evolves  in  areas  such  as 
software  engineering  and  Total  Quality  Management  (TQM).  It  will  elaborate 
on  software  development  practices  that  provide  dear  strategies  for  capability 
maturity  growth  and  improvement 

•  The  Empirical  Methods  Project  develops,  evaluates,  and  validates  products 
(e.g.,  questionnaires  and  tests,  methods  and  models)  for  use  in  baselining  and 
measuring  software  process  improvement 

•  The  Software  Process  Assessment  (SPA)  Project  helps  organizations  improve 
their  software  development  process  by  providing  a  structured  method  for 
assessing  their  current  practice.  It  also  is  continuously  improving  the 
assessment  method  and  ensuring  that  it  focuses  on  organizational  process 
improvement  The  objectives  of  the  assessment  method  are  to  identify  key 
areas  for  improvement  using  the  SEI  process  maturity  model  as  a  frameworlt 
and  to  help  the  organization  initiate  those  improvements. 

•  The  Software  Capability  Evaluation  (SCE)  Project  helps  DOD  acquisition 
organizations  evaluate  the  capability  of  contractors  to  develop  and  maintain 
software  competently.  The  project  is  improving  and  implementing  an 
evaluation  method  that  examines  the  software  process  of  contractors  for  use 
in  software-intensive  acquisitions. 


98 


Department  of  the  Navy 


Futura  Dirtellont 


1A2  Software  Risk  Management 

The  SEI  is  exploring  existing  techniques  and  developing  methods  for  managing  risk, 
assessing  practice,  preparing  organizations  to  manage  risk,  and  conducting  prototype 
risk  assessment  meth(^.  To  achieve  its  goals  and  objectives,  the  SEI  must  provide 
not  only  the  mechanisms  for  managing  risk  but  also  a  process  that  can  be 
implemented  within  a  project  and  organization  to  facilitate  the  communication  of  risk 
issues.  Communicating  risk  underlies  the  strategy  of  addressing  risk  throughout  the 
acquisition  process  and  strengthening  the  relationship  between  Government  and 
industry.  The  risk  focus  area  was  reorganized  in  July  1992  into  the  following  three 
projects  to  emphasize  its  customer  relationships: 

•  The  Government  Risk  Management  Projea  is  the  primary  interface  between 
Government  customers  with  respect  to  risk  management,  and  it  establishes 
collaborative  partnerships  for  developing  risk  management  methods.  Project 
staff  develop  and  conduct  interviews,  risk  assessments,  risk  assessment  training, 
and  risk  profiles.  Risk  management  methods  are  improved  through  active  field 
work  with  Government  and  industry  defense  programs.  The  project  is 
developing  methods  with  primary  firamework  of  the  acquisition  life  cycle.  The 
project  will  develop  methods  to  facilitate  and  strengthen  risk  communication 
through  a  rational,  visible  structure  for  identifying  and  analyzing  risk.  This 
project  is  concerned  with  creating  viable  methods  for  communicating  risks 
internally  within  programs,  whidi  includes  the  communication  of  risk  between 
the  Government  and  the  contractor  and  externally  to  higher  levels  of 
management. 

•  The  goal  of  the  Industrial  Risk  Manag&nent  Project  is  to  develop,  demonstrate 
and  transition  risk  management  pro^sses  and  techniques  to  an  industrial  client 
base.  The  project  intends  to  fulfill  its  mission  by  working  with  industry 
partners  to  demonstrate  methods  of  risk  identification— the  first  step  in  risk 
management— and  then  to  develop  the  succeeding  risk  management  steps  with 
a  small  number  of  strategic  industry  partners  who  are  likely  to  be  successful  in 
transitioning  software  risk  management  into  wide  use  on  their  projects. 

•  The  Risk  Taxonomy  Projea  is  refining  the  taxonomy-based  questionnaire  so  that 
it  can  help  identify  software  technical  risk  and  can  be  easily  used  by 
development  organizations.  The  strategy  of  the  Taxonomy  Project  is  to  derive 
a  softv^e  risk  taxonomy  by  analyzing  risk  assessment  data  and  other  related 
literature,  field  test  the  taxonomy-based  questionnaire,  and  modify  the 
questionnaire  based  upon  field  test  data.  The  Risk  Taxonomy  Project  also  is 
developing  analytical  methods  to  qualify  the  risks  identified  by  the 
taxonomy-based  questionnaire. 
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7.83  Real-Time  Distributed  Systems 

The  goal  of  improving  the  development  of  real-time  distributed  ^tems  is  achieved 

integrating  software  engineering  with  systems  engineering  and  reducing  the  risk 
associated  with  new  technology.  Projects  in  this  focus  area  include  the  following: 

•  The  Rate  Monotonic  Anafysis  (RMA)  for  Real-Time  Systems  Project  aims  to 
ensure  that  RMA  and  scheduling  algorithms  become  part  of  ^e  standard 
practice  for  designing,  building,  troubleshooting,  and  maintaining  real-time 
^tems.  RMA  helps  engineers  understand  and  predict  the  timing  behavior  of 
hard  real-time  systems  to  a  degree  not  previously  possible. 

•  The  Real-Time  Embedded  Systems  Testbed  Project  collects,  classifies,  generates, 
and  disseminates  information  about  Ada  performance  in  hard  real-time 
embedded  systems. 

•  The  goals  of  the  Real-Time  Simulators  Project  are  to  extend,  validate,  and 
document  flight  simulator  and  other  real-time  simulator  architectures  in  a  form 
accessible  to  practitioners  and  acquisition  personnel  and  to  understand  and 
codify  the  relationship  between  nonfunctional  qualify  goals  and  simulator 
software  architectures. 

•  The  Fault  Tolerance  Project  is  investigating  the  use  of  fault  tolerance  in  the 
design  and  implementation  of  dependable  critical  systems. 

•  TTie  Transition  Models  Project  is  developing  a  set  of  methods  and  supporting 
materials  such  as  guidelines  and  ched^ts  for  planning,  implementing,  and 
assessing  transition  activities.  These  materials  will  be  used  Ify  software 
technology  producers  and  consumers  both  inside  and  outside  the  SEI.  Project 
members  also  provide  other  SEI  staff,  including  management,  with  education 
and  training  on  .echnology  transition  roncepts  and  approaches.  Additionally, 
project  members  provide  limited  consulting  on  software  technology  transition 
to  members  of  the  SEI  constituencies,  and  maintain  contact  with  researchers 
and  others  interested  in  technology  transition  from  business  and  academic 
domains. 

•  The  objective  of  the  Zero-Defect  Applkation  Kemd  Project  is  to  develop  and 
transition  software  fault  tolerance  methodology  for  real-time  mission-critical 
fystems.  Projea  members  are  generalizing  the  rate  monotonic  scheduling 
theory  and  developing  software  fault  tolerance  methods  using  redundan^.  The 
project  will  combine  them  into  a  unified  software  engineering  firamework  for 
practitioners  who  must  meet  both  real-time  and  fault  tolerance  requirements. 
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7.8.4  Software  Eogineering  Techniques 

SEI  activities  related  to  software  engmeering  techniques  aim  to  increase  the  use  of 
engineering  knowledge  for  effective  and  efficient  production  of  large 
software-intensive  ^tems  through  a  model-based  software  engineering  approach  and 
engineered  project  support  environments.  The  projects  in  this  area  have  been 
integrated  around  a  common  technical  vision  and  strategy: 

•  The  CASE  Technology  Project  and  the  Software  Architectures  Engjmering  (SAE) 
Project  were  consolidated  into  the  CASE  Environments  Project  to  address 
issues  of  engineering  of  environments. 

•  The  Domain  Attalysis  and  the  SAE  Projects  were  consolidated  into  the 
Application  of  Software  Models  Project  to  address  the  systematic  creation  and 
application  of  models  in  application  engineering. 

•  The  Advanced  Video  Technology  for  Imaging  Project,  the  Requiranents 
Engineering  Project,  and  the  Software  Architecture  Design  Principles  Project  were 
consolidated  into  the  Software  Engineering  Information  Modeling  ^oject  to 
address  issues  of  capturing,  representing,  and  making  ;cessible  increasing 
amounts  of  engineering  information  ranging  from  requirements  to  engineering 
knowledge  typically  found  in  handbooks. 

7.83  Special  Projects 

The  SEI  is  also  involved  in  special  projects.  For  example,  the  Process  Research 
Project  investigates  the  factors  that  limit  software  development  performance  by 
conducting  research  on  the  use  of  software  process  principles  by  individuals  and  smoll 
teams.  This  research  is  seeking  insight  into  the  processes,  tools,  and  methods  that 
will  be  most  helpful  in  improving  the  performance  of  software  engineering 
professionals. 

73.6  SEI  Products 

With  the  goal  of  helping  end  users  help  themselves,  the  SEI  Products  group  works 
with  other  groups  in  the  SEI  to  develop  an  integrated  set  of  products  and  services 
for  managers,  practitioners,  and  educators.  SEI  Products  ensures  that  the  restilts  of 
SEI  work  are  in  a  form  the  software  community  can  easily  and  effectively  use  to 
improve  software  practice  and  educators  can  use  to  improve  software  engineering. 
SEI  Products  has  the  following  projects: 

•  The  Academic  Education  Project  fooises  on  the  long-term  development  of  a 
highly  qualified  work  force.  The  project  promotes  and  accelerates  the 
development  of  software  engineering  as  an  academic  discipline.  The  project 
is  developing  model  curricula  and  promoting  the  establishment  and  growth  of 
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software  engineering  programs,  as  well  as  working  to  increase  the  amount  of 
software  engineering  content  in  computer  science  programs.  The  project 
produces  educational  materials  that  support  the  teaching  of  softvme 
engineering  in  universities. 

•  The  Continuing  Education  Project  interacts  with  industry  and  Government  to 
increase  the  availability  of  hig^*quality  educational  opportunities  for  software 
practitioners  and  executives.  The  project  produces  the  Continuing  Education 
Series  and  the  Technology  Series.  The  Continuing  Education  Series  provides 
video-based  courses  designed  for  clients*  in-house  education,  and  execu 
offerings  designed  for  decision  makers  involved  in  improvement  efforts.  ; 
Technology  Series  provides  stand-alone  presentations  that  promote  awareness 
of  emerging  issues  and  leading-edge  technologies. 

•  CMU  offers  a  Master’s  in  Software  Engineering  (MSE)  Project,  a  16-month 
master’s  degree  program  in  software  engineering  in  response  to  industry’s 
growing  demand  for  skilled  software  developers.  The  program  is  a  cooperative 
effort  of  the  CMU  School  of  Computer  Science  and  the  SEI.  The  core  of  the 
program  is  based  on  the  SEI  currii^um  recommendations  for  MSE  programs. 
The  MSE  Project  also  produces  the  Academic  Series,  a  set  of  video-based 
graduate-level  courses  on  software  engineering. 

7A7  SEI  Services 

SEI  Services  works  with  other  groups  in  the  SEI  to  develop,  deliver,  and  transition 
services  that  support  the  efforts  of  SEI  clients  to  improve  their  ability  to  define, 
d^elop,  maintain,  and  operate  software-intensive  systems.  To  accelerate  the 
widespread  adoption  of  effective  software  practices,  SEI  Services  works  with  client 
organizations  that  are  influential  leaders  in  the  software  community,  promotes  the 
development  of  infrastructures  that  support  the  adoption  of  improved  practices,  and 
transitions  capabilities  to  Government  and  commercial  associates  for  use  with  their 
client  organizations.  SEI  Services  is  composed  of  the  following  groups  and  functions: 

•  The  Computer  Emergency  Response  Team  (CERT)  was  formed  by  ARPA  in 
November  1988  in  response  to  the  needs  exhibited  during  the  Internet  worm 
incident  The  CERT  charter  is  to  work  with  the  Internet  community  to 
fadhtate  its  response  to  computer  security  events  involving  Internet  hosts,  to 
take  proactive  steps  to  raise  the  community’s  awareness  of  computer  security 
issues,  and  to  conduct  research  targeted  at  improving  the  security  of  existing 
tystems. 

•  The  Improvement  Planning  arui  Organising  (IPO)  Function  focuses  its  activities 
on  SEI  clients  who  seek  long-term  support  for  their  software  process 
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improvement  efforts.  IPO  was  formed  to  address  needs  for  integrated  software 
process  improvement  programs.  These  include  understanding  the  principles  of 
how  to  effectively  launch  and  sustain  continuous  software  process  inq>rovement 
and  integrating  assessments,  organizational  dynamics,  the  maturity  model, 
process  definitions,  and  improvement  metrics  into  a  plan.  IPO  members 
provide  support  in  planning  and  organizing  continuous  software  process 
improvement  programs.  They  do  this  by  using  business  and  case  histories  in 
software  process  improvement  to  illustrate  benefits  achieved,  by  promoting  and 
la^inching  software  process  improvement  programs,  and  by  coordinating  a 
client’s  activities  with  the  work  of  different  SEI  projects. 

•  The  Organization  Capability  Development  Function  supports  clients’  software 
process  improvement  efforts  by  helping  the  client  organizations  develop  the 
capability  to  manage  the  organizational  aspects  of  improvement  at  their  sites. 
Services  include  organizational  assessment,  vision  setting  and  dissemination, 
strategic  planning,  transition  infrastructure  development,  executive  consulting, 
cross-functional  team  development,  and  management  of  technological  change, 
and  provision  of  consultation  for  software  engineering  process  groups.  The 
goal  of  the  function  is  to  provide  to  clients  the  self-sustaining  capability  of 
managing  their  own  long-term  improvement 

•  The  strategy  of  the  Technical  Assistance  Projea  is  to  define,  develop,  and 
implement  a  structured  technology-transition  process  that  will  establish  the 
requisite  technology-transition  capabilities.  This  process  will  enable  software 
technology  to  be  disseminated  broadly.  Applying  a  structured  transition 
approach  will  accelerate  the  transition  and  adoption  of  improved  software 
engineering  practices  and  technology. 

TS  SOFTWARE  EXECUTIVE  OFTICIAL  COUNCIL 

The  DON  Software  Executive  Official  Council  (SEOC)  will  serve  as  an  advisory 
committee  that  focuses  on  software-related  technology  and  polity  issues.  The  council 
will  address  software  issues  that  affect  AIS,  C3I  systems,  and  embedded  weapon 
system  software.  The  council  will  meet  quarterly  with  Flag  and  Senior  Executive 
^rvice  (SES)-level  representatives  firom  the  Chief  of  Naval  Operations  (CNO), 
Commandant  of  the  Marine  Corps  (CMC),  major  DON  Systems  Commands 
(SYSCOMs),  Program  Executive  Offices  (PEOs),  and  Navy  research  centers  and 
laboratories. 

7.10  SOFTWARE  TECHNOLOGY  FOR  ADAPTABLE,  RELIABLE  SYSTEMS 
STARS  is  a  technology  development,  integration,  and  transition  program  to 
demonstrate  a  process-driven,  domain-specific,  reuse-based  approach  to  software 
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engineeriiig  (also  known  as  megaprogramming)  supported  by  ^)propriate  tools  and 
environment  technology. 

The  goal  of  the  STARS  program  is  to  increase  software  productivity,  reliability,  and 
quality  Ity  tynergistically  integrating  support  for  modem  software  develq>ment 
processes  and  modem  reuse  concepts  into  the  latest  SEE  technology.  To  meet  that 
goal,  STARS  has  set  the  following  objectives  for  the  1992-95  time  frame. 

•  Software  Reuse.  Establish  the  basis  for  a  paradigm  shift  to  reuse-based 
development 

•  Processes.  Establish  capabilities  for  tailoring  process  definition  and 
management 

•  Environments.  Establish  adaptable,  commercially  viable  SEE  solutions  that  are 
available  on  miiltiple  vendors*  platforms,  are  built  upon  open  architecture 
industry  standards,  and  include  automated  support  for  process  management  and 
software  reuse 

•  Demtmsmttion  and  Validation.  Demonstrate  that  the  STARS  integrated  reuse, 
process,  and  SEE  solutions  can  be  used  in  actual  practice  to  increase  the 
quality  and  life-qrde  supportability  of  DOD  software  products 

•  Technology  Transitimi.  Sponsor  activities  and  disseminate  information  that  will 
speed  up  transition  of  STARS  technologies  to  practical  use. 

STARS  technical  development  addresses  new  areas.  Therefore,  STARS  program 
management  selected  three  prime  contractors — Boeing,  IBM,  and  Paramax — to 
reduce  risk  and  accelerate  acceptance  of  changing  technology.  Combining  the  efforts 
of  three  prime  contractors  will  enable  cooperative  work  to  be  accomplished  from  a 
very  bro^  e]q>erienoe  base.  Furthermore,  use  of  multiple  prime  contractors  and 
their  subcontractors  will  help  accelerate  ^e  shift  to  megaprogramming  in  other 
companies. 

7.10.1  Reuse 

STARS  is  working  to  establish  a  basis  for  a  paradigm  shift  to  reuse-based 
develc^ment  As  part  of  the  activities,  technical,  management,  cultural,  and 
acquidtion-related  issues  are  being  considered  with  the  goal  of  reducing  the  adoption 
riste  in  transitioning  to  reuse-based  software  engineering.  STARS  reuse  activities 
include  establishing  a  framework  for  reuse  processes,  providing  automated  support 
for  hey  processes,  and  e]q)erimenting  in  the  definition  and  prototyping  of  reuse 
library  open  architectures.  The  STARS  reuse  approach  focuses  on  an  iterative  model 
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that  addresses  technology  evolution  and  cultural  issues  with  a  trial-usage  and 
feedback  loop.  STARS  technology  transition  affiliates  provide  feedback  that  is 
incorporated  into  the  concept,  processes,  guidelines,  and  automated  tools.  The 
planned  reuse  results  include  reuse-transition  support  guidelines;  a  reuse-based 
concepts  document;  modular  descriptions  of  reuse  processes  associated  with  various 
user  roles;  a  reuse  library  open  architecture  framework;  reuse  library  mechanisms 
that  support  acquisition,  dassification,  browsing,  and  retrieval;  general  management 
of  reusable  assets;  and  additional  tools  to  support  the  various  reuse  processes. 

7.10J  Process 

STARS  will  establish  capabilities  for  process  definition  and  management  that  will 
show  the  value  of  process  concepts,  process  definition,  process  tailoring,  and  process 
support  in  the  envirorunent  as  a  vehide  to  improve  quality,  productivity,  and 
reliability.  Process  definition  and  tailoring  capabiUties  will  support  the  SEl  CMM. 
STARS  process  technology  transition  affiliates  will  provide  feedback  to  improve  the 
processes  and  products. 

7.10J  Environment 

STARS  is  working  with  framework  providers,  tool  vendors,  and  standards 
organizations  to  ensure  that  commerdally  viable  environment  infrastructures 
(frameworks)  are  extensible  and  robust  and  conform  to  open  architecture  standards. 
Framework-based  environments  serve  as  integration  platforms  on  which  tools, 
services,  and  functional  capabilities  can  be  integrated  to  support  software 
development  within  the  context  of  megaprogramming. 

7.10.4  Demonstration 

To  measure  the  success  of  STARS  technologies,  three  demonstration  projects  have 
been  selected  that  will  use  STARS  technologies  to  develop  operational 
mission-critical  applications  in  Ada: 

•  A  200,000  line-of-code  subtystem  of  the  Improved  Guardrail  V  system  will  be 
reengineered  by  an  in-house  support  contractor  at  the  Life-Ctycle  Support 
Center  at  the  Army  Communications  Electronics  Conunand  (CXCOM),  Ft. 
Monmouth,  New  Jersey.  (Application  domain:  Electronic  Warfare) 

•  A  200,000  line-of-code  subsystem  of  the  Space  Warning  Mission  will  be 
reengineered  with  contractor  support  at  Air  Force  Space  Command 
(AFSPACECOM),  Colorado  Springs,  Colorado.  (^pUcation  domain: 
Command  and  Control) 
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•  A  110,000  liiie-of>code  system  at  the  T-34C  Flight  Instrument  Trainer  will  be 
developed  at  the  Navy  Training  and  Simulation  Center  (NTSC),  Orlando, 
Florida.  (^)plication  domain:  Flight  Trainers) 

The  projects  will  be  designed  to  provide  a  pragmatic  measure  of  the  progress  STARS 
has  made  in  developing  and  introducing  new  software  engineering  approadies  and 
to  provide  realistic  and  useful  feedback  to  the  technology  developers.  Advanced 
planning  is  under  way,  and  mcecution  of  these  projects  is  scheduled  to  begin  in  late 
1993. 

7.103  Technology  Thinsftion 

STARS  is  developing  an  overall  technology  transition  strategy  that  identifies  specific 
activities  to  foster  the  transition  of  the  STARS  concept  and  technologies  to  practical 
use.  Technology  partnerships  have  been  formed  with  potential  customers  and 
suppliers  of  STARS  technologies  using  the  STARS  Tedmology  Transition  and  Prime 
Affiliates  Program  as  well  as  relationships  between  the  STARS  prime  contractors  and 
their  commercial  counterparts.  General  information  about  STARS  concepts  and 
technologies  is  disseminated  through  newsletters,  participation  in  selected  software 
conferences,  electronic  bulletin  boards,  and  the  annual  STARS  conference. 

7.11  TAC-4  AND  TAC-5  PROCUREMENTS 

The  Secretary  of  the  Navy,  the  Office  of  the  Secretary  of  Defense  (OSD),  and  the 
General  Services  Administration  (GSA)  have  ^>proved  the  TAC-4  contract  to 
procure  the  latest  high-performance,  open  systems-compliant  (insofar  as  current 
standards  allow)  computers  in  support  of  tactical,  strategic,  business,  and 
administrative  functions.  The  contract  is  a  3-year  indefinite  deUvery,  indefinite 
<]uantity,  fixed-price  ordering  contract  that  provides  for  3  additional  option  years  for 
maintenance. 

TAC-4  is  managed  by  the  Naval  Command,  Control,  and  Ocean  Surveillance  Center 
(NCCOSC)  in  San  Diego.  Designed  for  Navy  afloat  applications,  TAC-4  is  also 
arable  to  other  DOD  components,  other  U.S.  Government  agencies,  and  foreign 
nations  aligned  with  the  United  States.  The  Am^,  Air  Force,  Coast  Guard,  and 
Marine  Corps  have  already  presented  their  requirements  in  connection  with  the 
TAC-4  contract 

TAC-4  provides  a  suite  of  equipment  that  is  binary  compatible  and  required  to 
interfaM  downward  with  equipment  provided  by  the  previous  TAC-3  contract  Both 
ruggedized  suites  (i.e.,  standard  19-inch,  radc-mounted,  environmentally  hardened), 
and  purely  commerc^  suites  will  be  offered.  The  TAC-4  contract  provides 
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performance  incentives  for  the  higtMnd  equipment  The  TAC-4  will  be  procured 
with  an  Ada  capability.  The  requirement  is  based  on  the  stated  current  and  near- 
term  needs  of  the  user. 

The  TAC-4  solicitation  is  a  prime  example  of  the  DON*s  riding  the  price  and 
performance  curve  on  hardware,  achieving  a  common  operating  enviromneni, 
extending  it  beyond  command  and  control  to  other  forms  of  communications  and 
nontactical  applications,  and  doing  what  the  strategy  of  buying  off  the  shelf  is 
intended  to  do. 

The  TAC-5  contract  is  scheduled  to  follow  {q>proximately  24  months  after  the  TAC-4 
award  (i.e.,  in  May  1996).  The  purpose  of  the  rapid  turnaround  is  to  ensure  that  the 
Navy  maintains  currency  with  evolving  technology  and  benefits  from  the  attendant 
reductions  of  cost  per  unit  of  performance. 

7.12  PLANS 

Currently,  several  DOD  planning  initiatives  relating  to  Ada  and  Ada-related 
technologies  are  in  process.  The  subsections  below  provide  synopses  of  these 
activities. 

7.12.1  Software  Action  Plan 

The  Acting  Director  of  Defense  Research  and  Engineering  (DDR&E)  established 
the  Software  Action  Plan  Working  Group  (SWAP-WG)  in  June  1991  to  specify  and 
implement  \  .  .  an  integrated  technology  and  management  plan  to  ensure  more 
cost-  effective  support  of  weiqions  ^tems  and  related  test  equipment  ^tems  within 
DDR&E*s  purview."  The  SWAP-WG  directly  supports  the  SEOC,  whidi  is  diaired 
by  the  DDR&E. 

To  accomplish  its  mission,  the  SWAP-WG  has  addressed  high*leverage  software 
management  and  technology  issues  to  support  four  basic  goals: 

•  Assist  the  DOD  in  establishing  a  proactive  acquisition  and  life-^de 
management  process 

•  Identify  and  act  upon  opportunities  for  inq>roving  DOD  software  policies, 
standards,  and  guidance 

•  Identify  opportunities  to  strengthen  the  cs^abilities  of  the  DOD  software  work 
force 
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•  Support  and  capitalize  on  current  software  technology  programs  and  promote 
the  integration  of  the  resultant  products  into  other  SWAP-WG*  and 
DOD-SEOC-sponsored  efforts. 

Specific  efforts  in  which  the  SWAP-WG  has  thus  far  provided  funding  and/or 
technical  support  to  help  achieve  those  goals  include  the  following: 

•  Software  process  improvement 

•  Assessment  of  the  maturity  or  capability  of  software  acquisition  organizations 

•  Software  risk  assessment 

•  Core  set  of  software  metrics 

•  Software  reengineering 

•  High-level  language  polity 

•  Software  life-cycle  standards 

•  Software  cost  reporting  standards 

•  Standards-based  architectures  for  weapon  system  software 

•  Software  engineering  environment  standards 

•  Software  education  for  DOD  senior  executives 

•  Enhancements  to  the  software  personnel  base 

•  Enhancements  to  the  DOD  software  technology  base. 

Tbe  SWAP-WG  has  been  successful  in  leveraging  the  expertise  of  its  membership 
and  the  limited  resources  available  to  it  and  has  served  as  an  effective  mechanism 
for  addressing  numerous  DOD  software-related  issues.  DDR&E’s  and  SEOCs 
continued  support  of  the  SWAP-WG’s  efforts  will  enable  the  entire  Department  to 
reap  additiontd  benefits  in  addressing  the  many  managerial  and  technical  challenges 
presented  tty  DOD’s  increased  reliance  on  software. 

7.12.2  Draft  DOD  Software  Technology  Strategy  Document 
In  December  1991,  a  Draft  DOD  Software  Technology  Strategy  Document  was 
completed  and  distributed  for  public  review  and  comment  This  document  justified 
a  coordinated  set  of  DOD  software  science  and  technology  actions  and  investments 
that  would  meet  DOD  needs  for  improved  software  functionality  and  that  would 
bring  future  DOD  software  costs  under  control.  It  identified  the  following  two  levels 
of  software  technology  investments: 

•  A  current  program  that  could  be  implemented  within  currently  programmed 
budget  levels 

•  An  achievable  program  that  focuses  on  more  cost-effective  levels  of  software 
tedmology  that  could  be  realized  with  higher  levels  of  funding. 
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The  document  covers  a  '  ^-year  period  oi  DOD  software  technology  investments 
between  FY92  and  FYOT  provides  more  detail  for  the  first  5  years. 

The  Draft  DOD  Software  Technology  Strategy  Document  was  used  as  the  baseline 
for  a  new  DOD  Software  Technology  Initiative  (STI)  program  that  will  begin  in 
FY94.  The  STI  program  represents  a  focused  and  integrated  initiative  to  accomplish 
the  following: 

•  Provide  significant  and  timely  boosts  to  DOD  thrust  areas  through 
experimental  use  of  software  technologies  on  advanced  technology 
demonstrations 

•  Provide  support  for  new  and  existing  ^tems  by  addressing  current  voids  in  the 
DOD  softie  science  and  technology  program. 

The  military  departments  and  ARPA  will  plan  and  execute  the  Sn  progrant  The 
DDR&E  retains  approval  authority  for  the  plan  and  its  subsequent  executioiL 

7.12.3  DON  Reuse  Implementation  Plan  and  Guide 

The  DOD  estimates  that  expenditures  for  developing  and  maintaining  software  for 
its  weapons,  command  and  control,  and  other  automated  information  ^tems 
currently  exceed  $24  billion  a  year.  In  an  attempt  to  better  manage  these  costs  and 
improve  its  ability  to  develop  and  maintain  high-quality  software,  DOD  has  initiated 
a  comprehensive  effort  to  incorporate  software  reuse  practices  into  its  software 
development  efforts. 

DON  has  developed  the  Draft  DON  Software  Reuse  Implementation  Plan  to 
establish  a  reuse  infrastructure  in  the  DON.  This  plan  will  establish  systematic  and 
structured  software  reuse  as  an  integral  part  of  the  DON  software-^tems 
development  and  acquisition  process.  DON  believes  systematic  and  structured  reuse 
can  help  decrease  the  cost  of  software  acquisition  and  development.  In  addition,  the 
DON  believes  that  an  effective  reuse  infrastructure  will  improve  software  reliability, 
productivity,  portability,  and  interoperability. 

Planned  initiatives  include  the  following: 

•  Establish  DON-wide  reuse  policies,  standards,  and  guidance. 

•  Establish  a  Reuse  Manager  under  the  CNO  to  provide  oversight  on  the  DON 
reuse  initiative. 
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Establish  Domain  Managers  to  manage  the  domain  engineering  activity  within 
eadi  PEO  and  SYSCX)M  activity. 


•  Establish  Reuse  Coordinators  to  identify  sources  within  PEOs  and  SYSCOMs 
and  to  share  reusable  conq)onents. 

•  Develop  incentive  programs  to  produce  loi^-term  cost  savings  from  effective 
reuse  for  all  levels  of  DON,  to  include  PEOs,  SYSCOMs,  and  Direct  Reporting 
Program  Managers  (DRPl^). 

•  Establish  a  DON  Reuse  Executive  Council  (a  function  of  the  DON  SEOC)  to 
develop  reuse  policies,  standards,  and  guidance. 

•  Establish  an  education  and  training  program  targeting  the  DON  software  reuse 
concepts  for  senior  executives. 

•  Establish  a  Domain  Analysis  Pilot  Project  under  the  CNO  to  use  as  a  basis  to 
build  a  DON  reuse  infrastructure. 

7.12.4  DON  Information  Management  Strat^c  Plan 

Pursuant  to  Defense  Management  Review  Decision  (DMRD)  918,  the  DON  is 
turning  most  Navy  and  Marine  Corps  Central  Design  Activities  (CDAs)  and  Data 
Processing  Installations  (DPIs)  over  to  the  Defense  Information  Systems  Agenqr 
(DISA)  for  management  In  the  future,  DON  will  be  receiving  software  development 
and  operations  support  from  DISA  on  a  cost>reimbursable,  fee-for-service  basis.  To 
accommodate  this  change  and  to  focus  increased  attention  on  the  information 
management  functions  that  remain  with  DON,  the  Naval  Information  Systems 
Management  Center  (NISMC)  has  initiated  DON-wide  strategic  planning  for 
information  and  computer  resources.  Emphasis  over  the  next  year  will  be  on  the 
following: 

•  Developing  a  common  naval  shipboard  hardware  and  software  architecture  for 
Navy  and  Marine  Corps  afloat  and  amphibious  tactical  support  and  combat 
service  support  functions.  This  architecmre  for  the  Naval  Tactical  Combat 
Support  System  (NTCSS)  will  permit  integration  of  tactical  and  tactical-support 
of  the  Naval  Expeditionary  Forces  under  the  new  naval  maritime  strategy. 

•  Developing  Service-level  agreements  for  support  to  DON  activities  from 
DISA-managed  CDAs  and  DPIs  and  institutionalizing  unit  costing  and  a 
fee-for-seivice  structure.  DON  expects  to  generate  new  cost  savings  by  taking 
advantage  of  lower  rate  structures  generated  through  economies  of  s^e. 
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•  Improving  base-level  computing  and  communications  support  capabilities  by 
migrating  from  the  current  heterogeneous  sole-somce  environment  toward  a 
die-  -server  architecture  that  is  open-systems  compliant,  most  cost-effective, 
arc  jss  personnel  intensive.  Standard  acquisition  vehides  will  be  used, 
es'  -lally  ongoing  DISA  Indefinite  Quantity  contracts  and  Basic  Ordering 
Agreements. 

•  Optimizing  the  Return  On  Investment  (ROI)  for  all  DON  information 
technology  expenditures  by  putting  into  place  ^e  FPI  management  process 
initiated  by  OSD  under  OM  and  institutionalizing  the  requirement  for 
Functional  Economic  Analysis  as  justification  for  information  technology 
acquisitions. 

•  Making  DON  information  practices  more  effective  by  continuing  or  initiating 
the  following  management  improvements: 

-  Partidpating  actively  in  DOD  data  element  standardization  efforts 

-  Focusing  life-cycle  management  attention  on  economic  issues  (e.g.,  ROI 
and  real  cost  savings)  and  bringing  the  expertise  of  the  Naval  Center  for 
Cost  Analysis  (NCA)  to  bear  at  key  decision  points 

-  Developing  a  standard  software  engineering  environment  through  a 
combination  of  initiatives  such  as  the  following: 

I-CASE  Pilot  Program 
Ada  Implementation  Guide 
STARS/ ARPA  Demonstration  Project 
Reuse  Implementation  Plan  and  Guide 
DON  SEOC 

Multilevel  Information  Security 

-  Developing  a  standard  DON  information  technology  technical  architecture 
in  conformance  with  the  Defense  Information  Infrastructure  Technical 
Architecture  For  Information  Management  (TAFIM). 

7.12,5  Software  Process  Improvement  Plan 

The  SPI  Plan  is  based  on  the  SEFs  CMM,  which  is  a  five-level  framework  of  key 
process  areas.  This  framework  characterizes  the  maturity  that  organizations  use  to 
establish  or  improve  their  software  processes.  It  is  assumed  that  the  maturity  level 
of  development  and  maintenance  organizations  directly  correlates  to  their 
development  capabilities.  DON’S  goal  is  to  develop  a  program  where  all  software 
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development  and  maintenance  oisanizations  undertake  self-inq)rovement  programs 
to  raise  their  maturity  levels.  Initiatives  indude  the  following: 

•  Develop  a  DON>wide  SPI  inq>lementation  plan. 

•  Develop  a  training  program  to  educate  or  enhance  management  understanding 
of  the  effects  of  software  on  acquisition,  development,  and  post-deployment 
software  support  strategies. 

•  Ffihanro  the  Software  Process  Advisoiy  Group  to  help  institutionalize 
continuous  process  improvement  through  the  sharing  of  lessons  learned. 

The  SPI  Implementation  Plan  calls  for  the  use  of  an  SCE  as  part  of  the  source 
selection  process  for  all  new  programs  started  in  FY94  through  FY96. 

The  Director  of  Defense  Information,  as  part  of  an  Information  Technology  Policy 
Board  (ITPB)  initiative,  requested  volunteers  from  the  Services  to  partidpate  in  an 
SPA  The  Navy  Fleet  Material  Support  Office  (FMSO)  and  Naval  Research  and 
Development  (NRaD),  a  division  of  the  Naval  Command,  Control,  and  Ocean 
Surveillance  Center,  volunteered  to  partidpate  in  this  program.  The  FMSO 
assessment  has  been  completed;  the  NRaD  assessments  began  in  August  1993. 

The  most  important  benefit  FMSO  gained  from  this  assessment  was  the  intensified 
focus  on  the  need  for  formal  software  process  improvement  The  assessment 
provided  the  process  for  formally  identifying  key  areas  throughout  the  organization 
that  needed  improvement  and  a  baseline  on  which  to  measure  future  improvement 
The  resulting  action  plan  will  now  allow  FMSO  to  rank  improvement  efforts  based 
upon  need  and  funding  availabilify. 

7.13  DON  TECHNOLOGY  PILOT  PROJECTS 

The  DON  is  involved  in  several  pilot  projects  that  will  implement  many  of  the 
software  engineering  prindples  and  Ada  features  discussed  in  Uiis  guide  in  r^-world 
situations.  The  sections  below  briefly  describe  these  projects. 

7.13.1  Integrated  Computer-Aided  Software  Engineering  Pilot  Project 
The  I-CASE  procurement  as  discussed  in  Section  7.4,  is  a  major  DOD  initiative,  led 
the  Air  Force,  to  procure  an  Ada-based  integrated  computer  engineering 
environment  and  associated  services,  something  software  developers  in  DOD  have 
been  lacking  for  a  long  time. 
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Thf  Director  of  Defense  Information  requested  nominations  for  pilot  projects  from 
V  Services,  and  four  of  the  nominaicJ  DON  pilot  projects  were  selected.  These 
: '  jjects,  which  will  begin  immediately  after  contract  award,  are  as  follows: 

•  Marine  Air/Ground  Task  Force  Lt^isSics  Automated  Information  Syrian.  This 
mid-size  pilot  project  proposes  to  conduct  both  reengineering  and  reverse 
engineering  actions  on  the  seven  systems  that  support  mobilization  and 
deployment  of  various  Fleet  Marine  Force  Units. 

•  Communication  Support  System  Standard  Communication  Environment.  This 
project  addresses  the  redesign  and  integration  of  the  configuration  control, 
status  monitoring,  and  performance  monitoring  modules  of  the  real-time 
communication  management  requirements  for  Navy  tactical  communications, 
including  satellite  and  line-of-si^t,  high-frequency  radio  systems. 

•  Navy  Tactical  Command  Systems  A^ntt.  By  using  rapid  prototyping  techniques, 
this  pilot  project  will  develop  an  automated  reasoning  module  for  analyzing 
combat  information  related  to  engagement  analysis,  commander’s  estimates, 
effects  on  sensors  and  countermeasures,  and  decoy  diffusion  or  drift.  This 
module  also  will  include  a  decision  support  system  to  assist  tactical 
commanders  in  effectively  using  critical  elements  of  information  associated  with 
hard-  or  soft-kill  actions. 

•  Automation  of  Procurement  and  Accenting  Data  Entry.  This  project  consists 
of  reverse  engineering  that  uses  ^a  on  one  of  eight  subsystems  that  support 
monitoring  and  management  of  the  procurement  process.  This  system  is 
currently  in  CX)BOL. 

The  successful  introduction  of  I-CASE  into  DOD  in  the  future  will  depend  greatly 
on  the  outcome  of  the  pilot  projects  established  by  the  DDL 

7.13  J  Functional  Process  Improvement 

Early  in  1992,  DON  initiated  a  program  to  assess,  through  four  pilot  projects,  the  FPI 
methodology  and  management  process  proposed  by  OSD  for  process  improvement 
The  four  pilot  projects  were: 

•  Intermediate  maintenance  across  the  aviation,  surface,  and  submarine 
environments  in  the  DON 

•  Pay  and  personnel  data  collection  in  the  Personnel/Support  Activities  and 
Personnel  Support  Detachments 
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•  Funds  allocation  in  the  Weapons  Division  at  the  Naval  Warfare  Development 
Center 

•  Training  request  processing  at  Naval  Sea  Systems  Command  (NAVSEA) 
Human  Resources  Offices. 

Included  in  the  pilots  was  an  assessment  of  the  use  of  an  Integrated  System 

Definition  Language  (or  IDEF)  for  process  and  data  modeling.  Pilot  project 

managers  provided  fin^  briefings  on  3  March  1993. 

The  lessons  learned  from  the  pilot  projects  and  recommended  guidelines  for  future 

Project  Managers  are  being  published  in  a  DON  FPI  Implementation  Guide. 

7.13J  SEI  Pilots 

DON  is  working  closely  with  SEI  to  transition  SEI’s  technology  into  DON  projects. 

Some  of  the  following  projects  are  included  in  this  effort: 

•  Use  of  RMA  in  the  software  design  of  the  AN/BSY-2,  DON’S  largest  Ada 
project,  which  consists  of  2.4  million  lines  of  unique  Ada  code.  Other  modules 
reuse  12  million  lines  of  code  within  the  BSY*2. 

•  Transition  of  fault  tolerance  technology  to  the  Office  of  Naval  Research. 

•  Transition  of  RMA  principles  in  standards  for  NGCR  operating  ^tems  and 
LANs. 

•  Transition  of  a  measurement  program  for  improving  the  software  process  at  the 
Naval  Air  Warfare  Center. 

•  Development  of  software  architectural  components  for  the  AN /SSQ-94  trainer. 

•  Methods  and  processes  for  managing  and  communicating  software  risks  for 
PEO  for  Air  ASW,  Assault,  and  Special  Mission  Programs. 

•  Transition  of  visual  imaging  technology  for  converting  hard-copy  Naval  Supply 
Systems  Command  (NAVSUP)  engineering  drawings  to  computer-aided  design. 

•  Course  material  development  for  Space  and  Naval  Warfare  Systems  Command 
(SPAWAR)  OSA  training. 
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7.13.4  STARS  Demonstration  Pilots 

A  Memorandum  of  Agreement  was  signed  between  ARPA  and  NAVAIR  in  October 
1992  for  a  joint  project  to  i^ply  the  STARS  megaprogramming  paradigm  to  the 
rehost  upgrade  of  the  Navy’s  T-34C  FIT.  The  development  is  expected  to  start 
January  1994  and  to  be  completed  in  October  1994.  Objectives  of  the  project  are 
follows: 

•  To  build  a  real  software-intensive  product  by  using  a  process-driven, 
domain-speciHc,  reuse-based,  and  technology-supported  approach 
(megaprogramming) 

•  To  measure  the  benefits  of  megaprogramming  and  provide  feedback 

•  To  transition  the  demonstration  organizations  to  megaprogramming. 

This  demonstration  project  is  part  of  a  SHOW  ME  philosophy.  If  successful,  it  will 
encourage  other  DON  projects  to  transition  to  megaprogramming. 
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section  8 

Training  and  Education 

This  section  provides  practical  information  on  inqdementing  an  Ada  training  and 
education  inogram.  Topics  indude  (1)  organizational  tniningiequiiements,  (2)  trainiqg 
and  infonnation  sources,  and  (3)  tessons  learned  and  recommendations. 

The  successful  transition  of  new  technology  into  an  organization  is  directly  rdaled  to  die 
effectiveness  of  die  training  and  education  program  that  introduces  it.  Any  education  and 
training  program  must  focus  inrimarily  oa  software  engineering  and  teadi  Acte  in  the 
context  of  a  tool. 

Introducing  Ada  within  an  organization  donands  the  devdopment  of  a  well-jdanned 
education  and  training  program  tailored  to  die  needs  of  die  organization.  Ride  to  a 
program  is  minimized  if  education  and  training  are  sufficiendy  funded  and  adecpiately 
planned. 

8.1  ORGANIZATIONAL  TRAINING  REQllREMENTS 

Organizations  vary  widely  in  dieir  structure,  in  die  indications  di^  use,  and  in  didr 
training  requirements,  but  all  organizations  teoe  similtf  education  and  training  needs. 

8.1.1  Course  Ccmtoit 

Training  and  education  ate  needed  in  the  areas  of  Ada  orientation,  programming 
language,  software  engineering,  development  support  environments,  and  project 
managmnent.  The  following  course  tqncs  are  recommended  for  each  sifoject  area: 

•  Ada  Orientation 

-  History  of  Ada 

-  Software  engineering  principles  and  the  way  Ada  siqiports  diem 

-  Pros  and  cons  of  using  Ada 

-  Unique  features  of  Ada 

-  Pham  of  die  software  system  life  ^de 

-  Amcnmt  of  effort  associated  with  eadi  phase 

-  Cost  associated  with  each  ptasc 

-  Features  of  Ada  targeting  software  maintenance 

-  Ada  procumnent  strat^es 

-  Ada  as  an  alternative  to  odier  languages 

-  Object-Oriented  Derign  (OOD)  constructs 

-  Reuse 

-  Unique  training  aspects  of  Ada 

-  Computer-Aided  Software  Engineering  (CASE)  tool  overview 
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-  Efftcts  on  tile  scrftwaie  life  cyde  of  usiog  Ada 

-  Inqioftaiioe  of  oonfiguntion  management 

•  Ada  Progfamming  Language 

-  Introduclocy  Couraes 

Software  engineering  oonoqKs 
OQD 

libraries  and  reuse 
Ada  background 
Program  units 

Packages  first,  tiien  subprograms 
T«<tantia«Mw  end  usc  of  generic  units 
Sqieiate  compilation 
Eariy  interfece  testing 

Types  (including  access,  private,  and  limited  private  types) 

Subtypes,  dedaiations,  and  statements 
Excqnions  and  excqition  handling 
Etaborstion  and  execution  definition/dilferenoes 
Daily  hands^m  and  practical  woricshops 
IiqNit/Output  (I/O) 

Tsridng  overview 

-  Advanced  Couraes 

Concurrency  and  tiie  tasking  model 
Real-time  programming 

Low-levd  features  such  as  rqnesentation  clauses 
Pragmas 

Interfeces  with  otiier  languages,  modules,  and  databases 
Creation  of  generic  units  and  planning  fee  reuse 
Design  and  reusability 
Daily  hands-on  and  practical  woriohops 
Performance  profiling 

•  Software  Enpneering  Using  Ada 

-  Software  enpneering  oonoqits 

-  OOD 

-  Ada-qiecific  deagn  oonaderations  (e.g.,  data  typing,  structures,  excqKion 
handl^ 

-  Software  standards  and  documentation  requirements 

-  System  development  life  cycte  (e.g.,  requirements  analysis,  deagn, 
im|tiementation,  testing,  maintenance) 

-  Deagn  of  reusable  components  (generics) 


118 


Departnwnt  of  the  Navy 


Training  and  Educaden 


-  Sekctkm  and  uae  of  database  and  file  stniegies 

-  Progfimining-iiHhe-laise  issues 

•  Ada  Devdofmient  Support  Environment 

-  Tiaining  tailored  to  qiedfics  of  hardware  and  user  inter&oe 

-  Extensive  on-line  exercises 

>  Ubrary  management  and  configuration  contnd 

-  Sdectkm  and  use  of  tools  (e.g.,  text  editon,  linkers  or  loaders) 

-  Selection  and  use  of  compilers  and  auttnnated  tutorials 

•  Ada  Project  Management  and  Cost  Estimating 

-  Software  engineering  concqjts 

-  Software  Quality  Assurance  (QA) 

>  Configuratian  management  (e.gM  performance  baselines  and  dianges) 

-  Measurement  of  cost,  productivity,  and  risk 

-  Prototyimg  0.e.,  versus  evdutiooary) 

-  Resource  allocation  (e.g.,  hardware,  staff,  training) 

-  Software  sizing 

>  Portability 

-  Reuse 

-  Sources  of  information. 

8.1,2  Evatamtion  of  Edncatkm  and  Tirainfaig 

In  order  for  die  Dqwrtment  of  die  Navy  (DON)  to  successfully  and  cost-effocdvdy 
evdve  toward  modm  software  engineering  practices  using  die  Ada  programming 
language  ftnr  all  omipuler  systems,  education  and  training  programs  must  be  wdl  planned 
and  critically  evaliu^.  The  paragnphs  below  provide  guiddines  for  diis  task. 

8.1.2.1  Target  Audienoe  and  Environmmd 

Plarmers  should  define  die  target  audience  and  environment  for  training  by  evaluating  the 
cat^ories  of  personnel  and  available  ftidlities.  Analynsriiould  be  conducted  to  identify 
the  amount,  degree,  and  level  of  training  required  ftir  an  individual.  Course  prerequisites 
should  be  enforced  so  dial  instructors  do  not  digress  ftom  presentation  of  targeted 
material  to  remedy  defidendes.  Next,  die  environment  should  be  analyzed  in  terms  of 
computer  fodlities,  tools,  prqject  types,  and  project  deadlines.  The  forties  and  tools 
needed  for  training  may  be  already  available,  or  a  procurement  lead  time  may  be 
involved.  The  types  of  projects  and  dieir  deadlines  shm^  be  reviewed  to  ensure  planned 
training  matdies  woridoad  requirements  and  schedules.  Optimally,  training  should  b^in 
and  end  immediatdy  before  actual  project  woric  is  scheduled.  This  type  of  scheduling 
is  complex  and  dqiendent  on  many  interactive  foctors.  Charting  tediniques  are  useful 
to  clearly  show  tndning  and  project  dependencies. 
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8.UJ  TfanlDg  and  Course  Length 

The  tuning  of  education  and  training  is  The  optimum  solutuxi  is  to  have  a  Ailly 
qualified  Ada  manager,  engineer,  or  programmer  emerge  from  the  training  process  and 
immediately  beccmie  part  of  an  active  Ada  project.  The  time  lag  betwm  training 
completion  and  task  commencement  should  be  kepi  to  a  minimum.  If  dday  between  the 
two  is  unavoidable,  provision  should  be  made  fw  refresher  training  to  be  available  udien 
required. 

For  introductory  courses,  3  to  5  class  days  are  needed  to  teach  the  basics  of  the  language 
and  to  introduce  the  und^ying  software  engineering  principles.  For  advanced  classes, 
10  to  20  class  days  are  needed  to  present  the  material  and  enable  trainees  to  understand 
the  complexity  of  the  subject  matter  and  become  proficient  with  the  langu^e,  compilers, 
and  automated  tools.  For  executive  overvievra  and  briefings,  2  to  8  hours  are  required 
to  present  and  discuss  the  unique  attributes  and  requirements  of  software  engineering 
using  Ada.  At  least  S  days  should  dapse  bdween  courses  to  allow  students  time  to 
digest  course  material. 

8.1^^  Testing 

Courses  should  provide  pretesting,  progress  testing,  and  post  testing  of  student 
knowledge  and  expertise.  Such  tests  allow  courses  to  be  tailor^  cost-effectively  to  the 
unique  requirements  of  the  students.  Pretesting  assesses  the  expertise  and  background 
level  of  the  class  as  a  whole  and  determines  the  beginning  achievement  levd  of  individual 
students.  It  also  hdps  instructors  to  direct  course  emphasis 
and  identify  ^qjedal  instructional  requirements.  Progi^  testing  provides  the  instructor 
and  students  widi  a  measurement  of  progress  and  mastery  of  the  subject.  Post  testing 
provittes  an  indication  of  the  knowledge  and  proficiency  achieved  by  the  student  and  of 
the  overall  course  effectiveness.  Consistently  ineffective  courses  should  be  dropped  from 
the  training  plan  or  redesigned. 

8.U.4  Location 

Dqpending  on  the  number  of  students,  on-site  training  is  usually  more  cost-effective  than 
off-site  training.  When  possible,  instructors  should  be  brought  to  the  site,  or  instructors 
already  on-site  should  be  used.  Tliis  approach  reduces  travel  and  pa  diem  costs  for 
students,  reduces  time  away  from  the  worl^laoe,  and  provides  training  in  the  actual  wofir 
environmoit  on  installed  Ada  compiles  and  automated  tools  to  be  used  with  actual 
project  work.  As  in-house  expertise  and  knowledge  increases,  in-house  staff  should  be 
used  to  update,  improve,  and  present  on-site  training  and  to  fimetion  as  moitors  to  less 
experienced  staff. 
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lltAINING  AND  INFORMATION  SOURCES 
Education  and  training  are  available  from  a  wide  variety  of  sources.  The  subsections 
bdow  provide  examjto  of  avulable  sources  of  training.  Appendix  A,  Sections  A.1.2 
and  A.3.1,  presents  information  on  accessing  these  sources. 

8^.1  Academic  InstituUons 

Aj^midix  A,  Section  A.S.l,  lists  civilian  academic  institutions  that  currently  teach  or  use 
Ada. 

8JtJ  DOD  Organizations  and  DOD-Sponsored  Activities 

Ada  training  and/or  information  is  available  from  the  following  Government  sources: 

•  Ada  Language  System/Navy 

•  Ada  Software  Engineering  Education  and  Training  Team 

•  AdaSAQE 

•  Air  Force  Institute  of  Technology 

•  Common  Ada  PSE  Interface  Set  (CAIS) 

•  Computer  Sciences  Sdiool  (Marine  Corps) 

•  Computer  Science  School  (Army) 

•  National  Audiovisual  Center 

•  National  Defense  Univeraty 

•  Naval  Postgraduate  School 

•  Software  Engineering  Inaitute 

•  United  States  Air  Force  Academy 

•  United  Stales  Air  Force  Technical  Training  School 

•  United  States  Army  Engineering  College 

•  United  Stales  Military  Academy 

•  United  States  Naval  Academy. 

Appendix  A,  Section  A.1.2  provides  information  on  how  to  access  these  sources. 

8^^  Catalog  of  Resooroes  fmr  Edocation  in  Ada  and  Software  Enginealng 
The  Catalog  of  Resources  for  Education  in  Ada  and  Software  Engineering  (CREASE), 
produced  by  AdalC,  lists  military,  commercial,  and  academic  sources  of  courses  for 
education  in  Ada  and  software  engineering.  The  document  is  available  on-line  and  may 
be  accessed  and  downloaded  from  the  ajpo.sei.cmu.edu  host,  as  described  in  Appendix 
A,  Section  A.2. 

8^.4  Other  Sources  of  Ada  Traiidng  Information 

Other  non-DOD  sources  that  may  provide  information  or  pointers  to  information  (m  Ada 
education  and  training  are  the  local  Special  Interest  Groups  tm  Ada  (SIG  Adas)  and  Ada 
Letters  published  by  tiie  Assodation  for  Computing  Machinery  (ACM).  Additionally, 


121 


Training  and  Education 

the  fdlowing  annual  conferences  are  good  aourees  of  Ada  and  software  engineering 
inform^on: 

•  ASEET  Symposium 

•  DOD  Software  Tedinology  Conference  (fbrmeriy  the  STSC  Conference) 

•  National  Conference  on  Ada  Technology 

•  SIGAda  Conference 

•  Tri-Ada  Conference 

•  Washington  Ada  Symposium. 

S3  LESSONS  LEARNED  AND  RECOMMENDATIONS 
The  points  listed  below  highlight  lessons  learned  from  DOD,  industry,  and  academia 
concerning  Ada  as  an  effective  software  engineering  tool.  The  most  significant  lesson 
is  that  management  commitment  is  critical  to  success.  The  sources  of  the  following 
lessons  are  indicated  in  parentheses  at  the  end  of  each  entry. 

•  Ada  must  be  taught  as  a  software  engineering  tool,  not  syntactically  as  yet  another 

programming  language. 

~  Software  engineerip"  education  is  mandatory  for  the  proper  use  of  Ada.  To 
accrue  the  desired  productivity  gains  and  cost  savings,  education  and  training 
in  the  features  of  Ada  feat  support  fee  inrinciples  of  software  engineering,  such 
as  modularity,  abstraction,  and  informatimt  hiding,  must  be  provided.  A 
low-level  syntactic  focus  on  Ada  as  a  language  is  ii^ective.  (SEI) 

>  A  study  on  Ada  education  and  training,  conducted  by  the  Armed  Forces 
Communicaticms  and  Electronics  Associatirm  (AFCEA),  indicated  that  training 
in  software  engineering  practices  was  both  fee  most  important  and  fee  least 
practiced  of  all  training  requirements.  The  AFCEA  surv^  were  ctmsistent 
on  this  point.  General  comments  often  were  made  that  the  high-levd  crmcqpts 
of  Ada  (e.g.,  padcages,  tasking,  gemrics,  strong  data  tyi»ng)  permitted  new 
opticms  in  software  architecture  and  design.  The  intelligent  use  of  tiiese 
concepts  would  have  great  benefit  ft)r  both  the  software  engineering  process 
and  the  quality  of  fee  resulting  desipi.  (AFCEA,  87) 

-  Teaching  should  not  be  done  solely  by  analogy,  (i.e.,  wife  ample 
transliteration  of  examples  fiom  other  languages).  Teadiing  by  analogy  alone 
will  feil  to  capitalize  on  the  power  of  tiie  many  new  software  engineering 
features  of  Ada.  Resultant  programs  will  be  "AdaBOL”  or  "AdaTRAN”  0-e., 
syntactically  Ada  but  semantically  cmstrained  by  tire  limitations  of  the  esdier 
language).  Moreovm,  if  analogy  alcme  is  used  in  teadiing,  the  student  is  less 
likely  to  readily  adopt  new,  more  powerful  ways  of  accomplishing  old  tastes 
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and  ways  mcne  suited  to  Ada,  and  to  take  advantage  of  *new”  Ada  features 
such  as  packages,  tasking,  exceptions,  aggregate  assignments,  and  use  of 
Boolean  expressions.  Studrats  must  be  taught  to  diink  in  Ada.  (SEI,  92) 

•  Hands-on  training  is  essential. 

-  Ada  educaticm  and  .raining  are  ineffective  without  hands-<Mi  experience  on 
actual  Ada  projects.  The  training  can  be  conducted  on  an  actual  project,  on 
a  pilot  study,  or  in  classroom  exercises.  Several  re^KHidents  to  the  AFCEA 
87  ^y  agi^  that  language  training  was  useless  without  sudi  immaHiate 
reinfbrcement.  Actual  project  experience  was  the  most  highly  recommended 
form  of  hands-on  training.  (AFCEA,  87) 

-  It  is  also  apparent  that  classroom  training  alone,  even  with  hands-on  exocises, 
does  not  prqrare  individuals  fully  for  actual  work  on  Ada  projects.  To  be 
fully  educated,  people  need  to  have  on-the-job  experience  either  on  an  actual 
Ada  project  or  on  a  pilot  project  with  actual  deadlines  and  goals.  (AFCEA, 
87) 

-  Examples  must  be  at  a  real  level  to  accderate  the  ability  to  apply  the  language 
techniques.  Students  have  difficulty  applying  new  ccmcqns  to  their  supplication 
areas  without  real-life  models  to  imitate.  Ada  compounds  the  problem  by 
having  new  omstructs.  Thus,  many  programmes  who  have  a  foundation  in 
Assembly  have  no  parallel  constnu^ts  to  which  to  rdate.  "Generics”  is  a  good 
example.  (AFCEA,  87) 

-  Additicmal  models  Q.e.,  analogies)  need  to  be  provided  to  fadlitate  the 
sqiplication  of  Ada  to  specific  projects;  for  example,  avionics  examples  could 
be  created  to  provide  real  Ada  coded  examples  to  show  how  Ada  solves 
problems  in  this  specific  appiicaticm  domain.  Models  are  needed  to  allow  new 
Ada  programmers  to  imitate  good  style  and  practices  rather  than  to  start  from 
scratch.  (AFCEA,  87) 

-  When  asked  about  learning  Ada,  several  interviewees  responded  that  there  is 
no  substitute  for  on-the-job  training.  (AFCEA,  87) 

~  It  is  impoative  that  hands-on  programming  exercises  be  a  major  component 
of  the  training  process.  It  is  just  as  difficult  to  build  computer  software  and 
learn  computer  languages  without  practical  sq^lied  work  as  it  is  to  learn  how 
to  repair  radar  sets  or  jet  engines  without  sqiplying  the  skills.  In  feet,  the 
more  detailed  the  training,  the  more  imperative  hands-on  exercises  become. 
For  example,  in  classes  dealing  with  using  Ada  for  a  specific  embedded 
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processor,  ttere  is  no  substitute  for  writing  software  with  the  otmiinler  and 
tool  set  that  will  be  used  on  the  actual  development  inogram.  The  software 
engineers  wtnldng  at  this  level  need  to  undbrstand  die  performance  and 
limitations  of  a  particular  tool  set.  (SEI,  92) 

•  Training  and  education  and  their  application  must  be  closely  aligned. 

-  Course  documentation,  materials,  and  models  should  be  relevant  to  the  actual 
work  envirvMiment.  For  example,  a  class  of  Automated  Information  System 
(AIS)  students  should  be  working  with  sample  Ada  programs  for  unclassified 
business  functions.  Normally,  instructors  should  follow  these  presentations  by 
asyigning  students  exercises  that  require  use  of  automated  compilers  or  other 
tools  so  that  students  will  master  the  subject  matter  with  han^-<m  training. 
The  compilers,  tools,  and  models  should  be  the  same  as  those  used  by  the 
students  in  their  actual  work  envirxmroents. 

-  It  is  important  to  assign  useful  work  in  Ada  immediately  after  training. 
Education  provided  too  long  before  actual  use  is  not  rdnforced  and  is  lost. 
(AFCEA,  87) 

-  In  general,  knowledge  retention  was  best  when  the  training  was  concurrent 
with  or  very  dose  to  actual  project  assignment  Training  benefits  were  judged 
to  be  essentially  lost  if  as  few  as  4  to  6  weeks  passed  between  the  training 
dass  and  project  assignment  (AFCEA,  87) 

-  From  the  point  of  view  of  students,  immediate  need  for  Ada  ddlls  is  the 
strongest  motivator  for  learning.  (AFCEA,  87) 

•  All  personnd  associated  with  an  Ada  devdopmoit  effort  require  some  levd  of  Ada 

education  and  training. 

-  Training  is  necessary  for  both  acquisition  and  devdopment  of  maintenance 
posonnd.  Software  designers,  systems  enginems,  Ada  programmers,  and 
software  managers  in  both  industry  and  Government  need  to  know  about  Ada 
and  its  associated  software  engineering  techniques.  Ada  training  should 
address  all  of  these  groups,  but  the  depth  and  kind  of  knowledge  needed  will 
vary  for  each.  (SEI,  92) 

-  Project  support  personnel  need  training  in  relevant  aspects  of  Ada.  (AFCEA, 
87) 
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•  Access  to  an  Ada  software  programming  expert  is  important. 

>  Student  access  to  an  Ada  programming  expert  also  was  found  to  be  bodi 
essential  and  effective  in  on-die-job  training  situations.  Having  available  a 
recognized  expert  to  answer  questions  and  provide  guidance  to  novice  learners 
was  a  good  catalyst  for  the  learning  jnocess.  (AFCEA,  87) 

-  It  is  useful  for  a  project  to  build  a  erne  group  of  knowledgeable,  wdl-trained 
individuals  to  serve  as  mentors  to  more  junior  personnel.  These  individuals 
must  be  very  knowledgeable  in  the  application  of  Ada  and  software 
engineering  and  in  the  project  domain.  Experience  has  shown  that  a  few  such 
individuals,  placed  in  key  positions  within  the  project,  can  have  a  stimulating 
effect  on  other  engineers.  (SEI,  92) 

•  CAI  is  good  for  supplementing  other  training  but  not  as  the  sole  method  of 
providing  training.  Available  methods  and  media  must  be  compared  against 
training  funds,  objectives,  and  desired  mitcome.  Lectures  with  some  visual  aids 
are  relatively  inexpensive  and  suitable  to  briefings,  overviews,  and  orientations. 

•  Providing  adequate  tools  and  using  only  validated  Ada  compilers  for  training  is 
important 

•  Adequate,  user-friendly  tools  greatly  enhance  the  acoq)tability  of  Ada, 
particulariy  by  profesaonal  programmers.  An  overtaxed  or  overloaded 
support  environment  often  creates  frustratimi,  whidi  is  displaced  to  the 
language.  For  example,  a  system  where  editor  lesponx  time  is  d^raded  wiU 
generate  a  n^ative  attitude  toward  the  language  although  the  editor,  not  the 
language,  is  at  fault 

-  Using  only  validated  Ada  compilers  is  recommended  so  that  students  are  not 
exposed  to  the  frustration  of  studying  an  Ada  feature  and  then  discovering  it 
does  not  work  in  their  training  enviremments. 

-  Although  use  of  nonvalidated  or  subset  compilers  may  seem  effective  or 
cmvenioit  in  tne  short  term,  productivity  on  the  job  will  suffer  when  studoits 
have  to  adjust  to  the  full  language. 

•  Ada  is  not  significantly  more  difficult  to  learn  or  teach  than  are  other  languages. 
Teachers  and  students  do  not  ftnd  Ada  ngnificantly  more  difficult  to  learn  and 
teach  than  alternative  languages,  and  student  reaction  is  generally  favorable. 
(Qmmunications  nf^Associationfor  Computing  Machinery  [CACM],  November 
92) 
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•  Teaching  Ada  effectivdy  requites  a  different  methodology  from  those  used  to  teach 
previous  languages.  Emphasis  needs  to  be  placed  on  aspects  such  as 
programming-in-the-laige,  team  development,  and  maintenance.  To  do  this  wdl 
requires  redesigning  old  lesson  plans  and  incorporating  libraries  of  software 
packages. 

Instructors  must  redesign  their  teaching  methodologies  to  teach  Ada  and  its 
powCT  effectively.  Pascal  style  and  methodolt^y  do  not  carry  over  to  Ada. 
(CACM,  November  92) 

-  Basic  language  constructs  in  Ada  take  longer  and  are  more  complicated  to 
teach  than  basic  language  constructs  in  Pascal.  Thus,  first  and  second 
programming  courses  require  mote  effort  from  the  instructor,  but  these  extra 
efforts  will  be  beneficial.  (CACM,  November  92) 

~  Students  should  be  exposed  to  "reading"  and  analyzing  Ada  software  systems 
before  "writing"  or  creating  them. 

-  Two  kinds  of  support  are  envisioned  for  an  Ada-based  freshman  course,  which 
are  currently  unavailable.  For  instance,  a  large  library  of  well-designed  Ada 
library  units  is  needed.  Abstract  data  types  are  not  raough.  Examples  are 
needed  that  illustrate  speciffc  key  features  of  Ada,  kinds  of  objects  and 
operations,  and  other  software  design  issues,  as  well  as  a  large  collection  of 
components  that  students  can  combine  into  interesting  systems. 
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AAS 

ABET 

ACEC 

ACES 

ACM 

ACSE 

ACUE 

ACVC 

AdalC 

AdaJUG 

AdaPSE 

ADP 

AES 

AFATDS 

AFB 

AFDSRS 

AFSC 

AFSPACECOM 

AI 

AIE 

AIS 

AIU 

AJPO 

ALS 

ALS/N 

AMMWS 

AMPS 

ANSI 

AP 

AP 

APB 

API 

APID 

APP 

APT 

ARB 

ARLB 

ARPA 

ASEET 


Advanced  Automation  System 
Ada-Based  Environment  for  Test 
Ada  Compiler  Evaluation  Capability 
Ada  Compiler  Evaluation  System 
Association  for  Computing  Machinery 
Association  Control  Service  Element 
Aircraft  Control  Unit  Emulator 
Ada  Compiler  Validation  Ciq>abiUty 
Ada  Information  Clearinghouse 
Ada  Joint  (Services)  Users  Group 
Ada  Programming  Support  Environment 
Automatic  Data  Proces^g 
Ada  Evaluation  System 

Advanced  Field  Artillery  Tactical  Data  System 
Air  Force  Base 

Air  Force  Defense  Software  Repository  System 

Air  Force  Systems  Command 

Air  Force  Space  Command 

Artificial  Intelligence 

Ada  Integrated  Environment 

Automated  Information  System 

Acoustic  Interface  Unit 

Ada  Joint  Program  Office 

Ada  Language  System 

Ada  Language  System/Navy 

Advanced  Millimeter  Wave  Seeker 

Advanced  Message  Processing  System 

American  National  Standards  Institute 

Acquisition  Plan 

Arithmetic  Processor 

Acquisition  Program  Basdine 

Application  Programming  Interface 

Application  Programming  Instructional  Department 

Application  Portability  Profile 

Advanced  Programming  Technique 

Acquisition  Review  Board 

Ada  Reuse  Library  Browser 

Advanced  Research  Projects  Agency 

Ada  Software  Engineering  Education  and  Training 


Ada  Implementation  Guide 


129 


Acronyms  and  AbbrovMom 


ASI 

Apfdicatian  Software  InterfKC 

ASIS 

Ada  Semantic  Interftioe  Spedficatioo 

ASP 

Acquiatioo  Stmtcfy  Plan 

ASR 

Ada  Software  RqMWtoiy 

ASSET 

Asset  Source  to  S(rftware  Engineering  Teduiology 

AST 

Advanced  Systems  Tedmology 

ASW 

Anti-Submarine  Warftue 

ASWSOW 

Anti-Submarine  Wartoe  Standoff  Weapon 

AT&T 

American  Tdqtoie  &  Telegraph 

ATCCS 

Army  Tactical  Command  and  Control  System 

ATD 

Aircrew  Training  Device 

ATE 

Automated  Test  Equipment 

ATF 

Advanced  Tactical  R^ter 

ATIP 

Ada  Technology  Bisertion  Program 

ATIS 

A  Tool  Int^ration  Standard 

ATRIM 

Aviation  Training  and  Readiness  System 

AVF 

Ada  Validatirm  Facility 

BAFO 

Best  and  Final  Offer 

BBS 

Bulletin  Board  System 

BNfS 

Broadcast  Message  Server 

BP 

Barlfplanft 

C2 

Command  and  Control 

C2I 

Command,  Control,  and  Intelligence 

C3I 

Command,  Control,  Communications,  and  Intdligence 

C4I 

Command,  Control,  Communications,  Computers,  and 
Intelligenoe 

CAB 

Common  Ada  Basdine 

CAD 

Computer-Aided  Design 

CAI 

Computer- Auled  Instruction 

CAIS 

Common  Ada  PSE  Interface  Set 

CALS 

Computer-aided  Acquisition  and  Logistics  Support 

CAM 

Conqwter-Aided  Manufacture 

CAMP 

Common  Ada  Kfissile  Packages 

CARDS 

Central  Archive  to  Reusable  Defense  Software  Program 

CASE 

Computer-Aided  Software  Engineering 

CAS  REPS 

Casualty  Rqxrrting  System 

CAUWG 

Commercial  Ada  Usms  Working  Group 

CAXI 

Common  Ada  XV^dow  Interface 

CC&I 

Command,  Control,  and  Intelligence 

ccnr 

International  Consultative  Committee  for  Telr^nqih  and 
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COIT 

CCP 

CCS 

CDA 

CDB 

CDIF 

CDPA 

CDR 

CDRL 

CECOM 

CERT 

CERT/CC 

CFE 

CGI 

CGM 

a 

OF 

OM 

CLNP 

CLOC 

CMM 

CMP 

CMS-2 

CMU 

CMU/SEI 

CNO 

COBOL 

COE 

COEA 

COMNAVCOMTELCOM 

COMSPAWARSYSCOM 

CONORS 

CORBA 

COTS 

CPDL 

CPP 

CPU 

CRADA 

CREASE 


International  C<m»iltative  Committee  for  Tel^rairti  and 
Telq>hone 

Code  Counting  Program 

Combat  Ccmtrol  System 

Central  Design  Activity 

Central  Data  Base 

CASE  Data  Interchange  Format 

Cmtral  Design  Programming  Activity 

Critical  Design  Review 

Contract  Data  Requirements  List 

Communications  Hectronics  Command 

Computer  Emergency  Response  Team 

Computer  Emeigency  Response  Team  Coordination  Centm* 

Contractor<Fumi^ed  Equipment 

Computer  Graphics  Interface 

Computer  Grs^hics  Metafile 

Conflguration  Item 

Central  Issue  Facility 

Corporate  Information  Management 

Connectionless  Network  Protocol 

Compiled/ Assembled  Lines  of  Code 

OqMibility  Maturity  Modd 

CoMPleteness 

Compiler  Monitor  System-2 

Cam^e-Mellon  Univ»sity 

Camegie-Mdlon  University/Software  Engineering  Institute 

Chief  of  Naval  Operations 

Common  Business  Oriented  Language 

Common  Operating  Environment 

Cost  and  Operational  Effectiveness  Analysis 

Commander,  Naval  Computer  and  Tdecommunications 

Command 

Commander,  Space  and  Naval  Warfare  Systems  Command 
Concept  of  Operations 

Common  Object  Request  Broker  Architecture 
Commercial  Off-The-Shdf 
Computer  Program  Development  Laboratory 
Command  Program  Processor 
Central  Processing  Unit 

Cooperative  Research  and  Devdopment  Agreement 
Catalog  of  Resources  for  Education  in  Ada  and  Software 
Engineering 
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CRISD 

Computer  Resource  Int^rated  Software  Document 

OtLCMP 

Computer  Resources  Life-Cycle  Management  Plan 

CRSS 

C3I  Reusable  Software  Systmn 

CRWG 

Computer  Resources  Working  Group 

CSC 

Computer  Sciences  Corporation 

csa 

Computer  Software  Omfiguration  Item 

CSRO 

Center  for  Software  Reuse  Operations 

CSS 

Centralized  Structure  Store 

csu 

Computer  Software  Unit 

CWG 

Coordinator  Woridng  Group 

D&V 

Demonstratitm  &  Validation 

DAB 

Defoise  Acquisition  Board 

DACS 

Data  and  Aiialysis  C^ter  for  Software 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DAT 

Digital  Audio  Tape 

DBMS 

Database  Managemoit  System 

DC 

Device  Coordinate 

DCDS 

Distributed  Computing  Dengn  System 

DCE 

Distributed  Computing  Environment 

DDI 

Directorate  of  Defense  Information 

DDN 

Defense  Data  Network 

DDR&E 

Director  of  Def<mse  Research  and  Engineering 

DDRS 

DOD  Data  Rq)ository  System 

DEI 

Data  Elements  in  the  Source 

DEM 

Digitized  Bectronic  Module 

DEMVAL 

Demonstration  and  Validatitm 

DECS 

Digital  Flight  Control  System 

DFU 

De  Facto  Usage 

DID 

Data  Item  Description 

DISA 

Defense  Information  Systems  Agency 

DMRD 

Defense  Management  Review  Decision 

DOD 

Department  of  Defense 

DODD 

Dqnrtment  of  Defense  Directive 

DODI 

Dqnrtment  of  Defense  Initiative 

DON 

Dqnrtment  of  the  Navy 

DPI 

Data  Processing  Installation 

DP/DGU 

Distributed  Processor/Di^lay  Generator  Unit 

DRFM 

Direct  Reporting  Program  Manager 

DS 

Directory  Service 

DSRS 

Defense  Software  Rqxmtory  System 

DTC2 

Desk  Top  Computer  2 
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DTK 

DTIC 

DUS 

D\VS 

ECCM 

ECLD 

ECLS 

ECM 

ECMA 

ECS 

EDI 

EDL 

EDSI 

EMPM 

EMR 

ENB 

EPROM 

EP 

ERA 

ESD 

ESM 

4GL 

FAA 

FAR 

FAU 

FCDSSA 

FE 

FFP 

FFRDC 

FIFO 

FIPS 

FIT 

FMSO 

FP 

FPI 

FRAWG 

FSD 

FTAM 
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Data  rnnsftr  Network 
Defenie  Technical  Information  Center 
Design  Unit  Specification 
Defensive  Wei^xxi  System 

Electronic  Counter-Countermeasures 

Embedded  Comment  Lines  in  Data 

Embedded  Comment  Lines  in  Source 

Electronic  Countermeasures 

European  Computer  Manufocturing  Association 

Electronic  Customer  Services 

Electrcmic  Data  Interchange 

Event-Driven  Language 

Equivalent  Ddivered  Source  Instructions 

Electronic  Manuscript  Prqiaration  and  Markup 

Extended  Memmy  Readt 

Engineering  Notebook 

Erasable  Programmable  Read  Only  Memory 

Enhanced  Processor 

Entity  Relationship  Attribute 

Electronic  Systems  Divison 

ElectTonic  Support  Measure 

Fourth  Generation  Language 
Federal  Aviation  Administration 
Federal  Acquisition  Regulations 
Fin  Actuator  Unit 

Fleet  Combat  Direction  System  Support  Activity 
Functional  Element 
Firm  Fixed  Price 

Federally  Funded  Research  and  Development  Center 
First  In  First  Out 

Federal  Information  Processing  Standards 
Flight  Instrument  'Dainer 
Fleet  Material  Support  Office 
Function  Point 

Functional  Process  Improvement 
Front  Range  Ada  Working  Groiq> 

Full-Scale  De^opment 

File  Transfer,  Access,  and  Management 


Ada  Imptamentation  Guida 


133 


Acfonyim  and  AMraviatiens 


FTP 

Rle  Transfer  Progrun 

ftp 

I^  Transfer  Protocol 

43RSS 

ANAJYK-43(V)  Run-Time  Siqiport  System 

GAO 

General  Accounting  Office 

GB 

Gigabyte 

GEU 

Guidance  Electionics  Unit 

GFE 

Government-Furnished  Equipment 

GFS 

Govemment-Furnisl^  Software 

GIS 

Geogn^rhic  Information  System 

GKS 

Grqrhical  Kernel  System 

GM 

Global  Memory 

GNCP 

Guidance,  Navigation,  and  Control  Program 

GNMP 

Government  Network  Management  Profile 

GOSIP 

Government  Open  Systems  Interccmnection  Profile 

GOTS 

Govemment-Off-the-Shelf 

GPEF 

Generic  Package  of  Elementary  Functions 

GPPF 

Generic  Package  of  Primitive  Functions 

GPO 

Government  Printing  Office 

GRACE™ 

Generic  Reusable  Ada  Components  for  Engineering 

GSIS 

Graphics  System  Interface  Standard 

GTRIMS 

Ground  Controller  Training  System 

GUI 

Gnqphical  User  Internee 

HOL 

High  Order  Language 

HP 

Hewlett-Packard 

HP  VUE 

Hewlett-Packard  Visual  User  Environment 

HPBP 

High-Perfonnance  Baclqplane 

HPP 

High-Performance  Processor 

IBM 

International  Business  Machines 

I-CASE 

Int^rated  Computer-Aided  Software  Engineering 

ICC 

Irvine  Compiler  Corporation 

ICE 

Independent  Cost  E^mate 

IDEI 

Int^rated  System  Definition  Language 

lEC 

International  Electro-Technical  Committee 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

IGES 

Initial  Grqrtucs  Exchange  Specification 

IGRV 

Improved  Guard  Rail  Five 

ILSP 

Int^rated  Ijogistics  Support  Plan 

IMU 

Initial  Measurement  Unit 

INEL 

Idaho  National  Engineering  Laboratory 
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INFOSEC 

InProc 

I/O 

IOC 

lOP 

IPO 

IPR 

IPS 

IPSE 

IRAC 

IRDS 

IRS 

ISA 

ISC 

ISON 

ISEA 

ISEE 

ISO 

ISSC 

TTPB 

ITS 

IV&V 


Infrainatioa  System  Security 
In  Processing 
Input/Output 

Initial  Operating  Ciqpability 

Input/Outyut  Processor 

Information  Planning  and  Organizing 

In-Process  Review 

Int^rated  Project  Summary 

Int^rated  Project  Siqiport  Environment 

International  Requirements  and  Design  Criteria 

Information  Resource  Dictionary  System 

Interftoe  Requirements  Specification 

Instruction  S^  Architecture 

Input  Signal  Conditioner 

Integrated  Services  Digital  Network 

In-Service  Engineering  Activity 

Int^rated  Software  Engineering  Enviremment 

International  Organization  for  Standardization 

Information  System  Software  Center 

Information  Technology  Policy  Board 

Integrated  Test  Software 

Independoit  Verification  and  Validation 


JCS  Joint  Chiefs  of  Staff 

JIAWG  Joint  Integrated  Avionics  Working  Group 

JIEO  Joint  Interoperability  and  Engineering  Organization 

JLC-JPCG-CRM  Jmnt  Logistics  Commanders  Joint  Policy  Coordinating 

Group  on  Computer  Resources  Management 
JTC  Joint  Technical  Committee 


K  1,000 

KAPSE  Kernel  Ada  Programming  Support  Environment 

LAN  Local  Area  N^ork 

LC^  Life-Cycle  Management 

LCSA  Ufe-Cyde  Suppmt  Activity 

LOC  Level  of  Consensus 

LRFP  Logistics  Requirements  Funding  Plan 


MAPSE  Minimal  Ada  Programming  Support  Environment 

MAT  MATurity 

MB  Megabyte 
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MCCDC 

MCCR 

MCCRES 

MCO 

MENS 

MEPS 

MHS 

MIL-HDBK 

MIL-STD 

MIMMS 

MIPS 

MIS 

mm 

MMI 

MMS 

MOA 

MOTS 

MSE 

MT 


NA 

NAC 

NADC 

NAPI 

NAPUG 

NARDAC 

NASA 

NASEE 

NATO 

NAUG 

NAVATR 

NAVCOMTELCOM 

NAVDAC 

NAVSEA 

NAVSUP 

NAVSWC 

NAWC-AD-WAR 


Marine  Corps  Combat  Development  Command 

Mission-Critical  Computer  Resources 

Marine  Corps  Combat  Readiness  Evaluation  System 

Marine  Corps  Order 

Mission  Element  Need  Statement 

Message  Edit  Processing  System 

Message  Handling  Service 

Military  Handbook 

Military  Standard 

Marine  Corps  Integrated  Maintenance  Management  System 
Millions  of  Instructions  per  Second 
Management  Information  System 
Millimeter 

Man-Machine  Interface 
Minimum  Mode  Software 
Memorandum  of  Agreement 
MiUtary  Off-The-Shelf 
Master’s  in  Software  Engineering 
Mission  Trainer 

Network  Adaptor 

Naval  Avionics  Center 

Naval  Air  Development  Center 

North  American  Portable  Common  Tool  Environment 

Initiative 

North  American  PCTE  User’s  Group 

Navy  Regional  Data  Automation  Center 

National  Aeronautics  and  Space  Administration 

NAVAIR  Software  Engineering  Environment 

North  Atlantic  Treaty  Organization 

Navy  Ada  Users  Group 

Naval  Air  Systems  Command 

Naval  Computer  and  Tdecommunications  Command 

Navy  Data  Automatimi  Command 

Navd  Sea  Systems  Command 

Naval  Supply  Systems  Command 

Naval  Surface  Warfare  Center 

Naval  Air  Warfare  Center,  Aircraft  Division,  Warminster 
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NCA 

NCCOSC 

NCS 

NCTAMS 

NCTAMSLANT 

NCTAMS  EASTPAC 

NCTC 

NCTS 

NDC 

NDI 

NGCR 

NISBS 

NIST 

NISMC 

NISO 

NIUF 

NM 

NOSC 

NRaD 

NSWC 

NTCSS 

Nns 

NUSC 

NWRC 

NWSUS 

OAS 

OASD 

OCD 

OFPS 

OMG 

OMU 

OOD 

OOP 

OORA 

OPE 

OPNAVINST 

OPR 

ORG 

OS 

OSA 


Naval  Center  for  Cost  Analysis 

Naval  Conunand,  Control,  and  Ocean  Surveillanoe  Center 

Network  CcMnputing  Service 

Naval  Computer  and  Tdecommunications  Area  Master 

Station 

NCTAMS  Atlantic 
NCTAMS  Eastern  Pacific 

Naval  Computer  and  Telecommunications  Command 

Naval  Computer  and  Telecommunications  Station 

Normalized  Device  Coordinate 

Nondevdopmental  Itmn 

Next  Generation  Computer  Resources 

NATO  Interoperable  Submarine  Broadcast  System 

National  Institute  of  Standards  and  Technology 

Naval  Information  System  Management  Center 

National  Informatira  Standards  Organization 

North  American  ISDN  Users*  Forum 

Netw(^  Management 

Naval  Ocean  Systons  Center 

Naval  Research  and  Development 

Naval  Surface  Weapons  Center 

Naval  Tactical  Combat  Support  System 

National  Technical  biformation  Service 

Naval  Undersea  Command 

Navy  Wide  Reuse  Center 

Navy  WWMCCS  Site-Unique  Software 

Offensive  Avimucs  System 
Office  of  the  Assistant  Secretary  of  Defense 
Operational  Qmcqn  Document 
C^terational  Flight  Program  Size 
Object  Management  Groiq) 

Operational  Mock-tq> 

Object-Oriented  Deagn 
Object-Oriented  Programming 
Object-Oriented  Requirements  Analysis 
Open  Systems  Environment 
Naval  Operations  Instruction 
Office  of  Primary  Re^nsibility 
Organization  Chain  of  Command 
Operating  System 
(^>en  Systems  Ardiitecture 
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OSD 

Office  of  the  Secretary  of  Defense 

OSE 

Open  Systons  Environment 

OSF 

Open  Software  Foundation 

OSl 

(^len  Systems  Intercminection 

OSISL 

C^ien  Systems  Interface  Standards  List 

OSS 

tolerations  Support  System 

OSSWG 

collating  Systems  Standards  WOTldng  Group 

PAV 

Product  Availability 

PC 

Personal  Computer 

PCIS 

Portable  Common  Interfece  Set 

PCTE 

Portable  Common  Tool  Environment 

PDL 

Program  Design  Language 

PDR 

Preliminary  Design  Review 

PDS 

Post-Deployment  Support 

PDSS 

Post-Deployment  Software  Support 

PDU 

Pulse  Driver  Unit 

PEO 

Program  Executive  Office 

PHIGS 

Programmer’s  Hierardiical  Interactive  Grairfiics  System 

pn 

Prmocol  Indq)endent  Interfece 

PIMB 

PCTE  InterfeM  Management  Board 

PIWG 

Performance  Issues  Working  Group 

PMC 

Project  Management  Charter 

POC 

Point  of  Contact 

POM 

Program  Objective  Memorandum 

POSK 

Portable  Operating  System  Interfece  for  Computer  Systems 

PPBS 

Planning,  Programming,  and  Budgeting  System 

PRISM 

Portable  Reusable  Int^rated  Software  Modules 

PRL 

PRoblems/Limitations 

PRR 

Product  Readiness  Review 

PSE 

Project  (or  Programming)  Suf^rt  Environment 

PSERM 

Project  Support  Envircmment  Reference  Model 

PSESWG 

Project  Support  Environment  Standard  WOTldng  Group 

PSA 

Program  Structure  Analysis 

PSL 

Program  Structure  Language 

RiU> 

Research  and  Development 

RACS 

R^istration  and  Access  Control  System 

RADC 

Requirements  and  Design  Criteria 

RAM 

Random  Access  Memory 

RAPID 

Reusable  Ada  Products  for  Information  Systems 
Development 
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RCL 

RAPID  Center  Library 

RDA 

Remote  Database  Access 

RDBMS 

Relational  Database  Management  System 

RDT&E 

Research,  Development,  Test,  and  Evaluatitm 

RES 

Resources 

REVIC 

Revised  Intermedia  COCOMO 

RFP 

Request  for  Proposals 

RLF 

Reuse  Library  Framework 

RLT 

Reuse  Library  Toolset 

RMA 

Rate  Monotonic  Analysis 

RMC 

Reconfigurable  Mission  Computer 

ROI 

Return  on  Investmmt 

ROM 

Read  Only  Memory 

RPC 

Remote  Process  Communication 

RPC 

Remote  Procedure  Call 

RSC 

Reusable  (Ada)  Software  Component 

RTAda 

Run-Time  Ada 

RTE 

Run-Time  Environment 

SAE 

Software  Architectures  Engineering 

SAFENET 

Survivable  Adaptable  Fiber-optic  Embedded  Network 

SAI 

Software  Action  Item 

SAIL 

System  Avionics  Int^ration  Laboratory 

SAME 

SQL  Ada  Module  Extension 

SAMeDL 

SQL  Ada  Module  Description  Language 

SASET 

Software  Architecture  Sizing  and  Estimating  Tool 

SASSY 

Supported  Activities  Supply  System 

SCAI 

Space  Command  &  Control  Architecture  Inftastructure 

sees 

Submarine  CombiU  Control  System 

SCE 

Software  Csqiability  Evaluatitm 

SCH 

Scheduler 

SCL 

Stand-alone  Commoit  Lines 

SCMP 

System  Conftguradmi  Management  Plan 

SCRB 

Software  Change  Review  Board 

SCS 

Submarine  Combat  System 

SDC-W 

Software  Developmoit  Center,  Washington 

SDD 

System  Design  Definition 

SDE 

Software  Devdopment  Environment 

SDF 

Software  Development  Folder 

SDIO 

Strategic  Defense  Initiative  Organization 

SDL 

Software  Development  Laboratory 

SDP 

Software  Development  Plan 
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SDP 

System  Diviaon  Paper 

SDR 

System  Design  Review 

SDSR 

Software  Devdopment  Status  Rqxnt 

SDTS 

Spatial  Data  Transfer  Standard 

SECNAVINST 

Secretary  of  the  Navy  Instruction 

SECNAVNOTE 

Secretary  of  the  Navy  Note 

SECR 

Standard  Embedded  Computer  Resource 

SEE 

Software  Engineering  Environment 

SEI 

Software  Engineering  Institute 

SEM 

Standard  Electronic  Module 

SEMP 

System  Engineering  Management  Plan 

SEO 

Software  Executive  Official 

SEOC 

Software  Executive  Official  Council 

SEPG 

Software  Engineering  Process  Group 

SES 

Senior  Executive  Service 

SGS/AC 

Shipboard  Gridlock  System  with  Auto-Correlation 

SGML 

Standard  Generalized  Markup  Language 

SIGAda 

Special  Interest  Group  on  A^ 

SIGSOFT 

Special  Interest  Group  on  Software  Engineering 

SIL 

System  Int^ration  L^ratory 

SIP 

System  Integration  Plan 

SISTO 

Software  and  Intdligent  Systems  Technology  Office 

SLCX: 

Source  Lines  of  Code 

SLOC/SM 

Source  lines  of  Code  per  Staff  Month 

SLOCWC 

Source  lines  of  Code  Without  Comments 

SMB 

Submarine  Message  Buffer 

SMM 

Software  Managemoit  Metrics 

SMP 

Software  Master  Plan 

SOW 

Statement  of  Work 

SPA 

Software  Process  Assessment 

SPAWAR 

Space  and  Naval  Warfare  Systems  Command 

SPC 

Software  Productivity  Cons^um 

SPD 

Software  Process  Definition 

SPDL 

Standard  Page  Description  Language 

SPI 

Software  Process  Improvement 

SPO 

System  Programming  Office 

SPR 

Software  Problem  Report 

SQAP 

Software  Quality  Assurance  Plan 

SQL 

Structured  Query  Language 

SRC 

Software  Requirements  Change 

SRR 

Software  Requirem«its  Review 

SRS 

Software  Requirements  Spedfication 
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SSA 

SSC 

^ANFINS 

STANFINS-R 

STARFIARS 

STARS 

STB 

STC 

STEP 

sn 

STSC 

SUP 

SWAP 

SWAP-WG 

SWG 

SWTP 

SYSCOM 

TAG 

TACAMO 

TACFIRE 

TAFIM 

TADSTAND 

TAMPS 

TC 

TC 

TCL 

TCP/IP 

TD 

TDA 

TDT 

TEMP 

TEP 

TFA 

TLCSCAiCSC 

TLOC 

TOES 


Software  Support  Activity 
ystem  Support  Center 
System/S^ment  Specification 
Standard  Financial  System 
Standard  Financial  System  Redesign 
Standard  Army  Financial  Accounting  and  Rqxvting  System 
Software  Technology  for  Adaptable,  Reliable  Systmns 
STaBiUty 

Software  Technology  Conference 

Standard  for  the  Exchange  of  Product  Model  Data 

Software  Technology  Initiative 

Software  Technology  Support  Centm* 

Support  Planning 
Software  Action  Plan 
Software  Action  Plan  Working  Group 
Special  Working  Group 
Software  Technology  Plan 
Systems  Command 

Tactical  Advanced  Computm* 

Take  Charge  and  Move  Out 
Tactical  Fire  Direction 

Technical  Architecture  For  Information  Management 

Tactical  Digital  Standard 

Tactical  Aircraft  Mission  Planning  System 

Target  Oqjacity 

Technical  Committee 

Total  Comment  Lines 

Transmission  Control  Protocol/Intemet  Protocol 

Technical  Directive 

Technical  Directive  Authority 

Theater  Display  Tnminal 

Test  and  £\^uation  Master  Plan 

Test  and  Evaluation  Plan 

Transparent  File  Access 

Top  Level/Lower  Level  Computer  Software  Component 
Total  Lines  of  Code 
Telephone  Order-Entry  System 
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TOPS 

TQM 

TSGCEE 


UIMS 

ULLS 

USMC 

USTAG 

USW 

UUT 

VADS 

VDI 

VHSIC 

VRC 

VSR 

VT 

WAdaS 

WAM 

WBS 

WC 

WFNIA 

WIS 

WPAFB 

WST 

WWMCCS 


Training  and  Operations  Section 
Total  Quality  Management 

Tii-Servioe  Gioiq>  on  Communications  and  Electronics 
Eququnent 

User  Inter&oe  Management  System 
Unit  Level  Logistic  System 
U.S.  Marine  Coti» 

United  States  Tedhnical  Advisory  Group 
Undersea  Warfiue 
Unit  Under  Test 

Verdix  Ada  Development  System 
Virtual  Device  Interface 
Very  Ifigh-Speed  Int^rated  Circuit 
Virtual  Reference  Coordinate 
Validation  Summary  Rqmrt 
Virtual  Terminal 

Washington  Ada  Symposium 
WWMCCS  ADP  Modernization 
Work  Breakdown  Structure 
World  Coordinate 

WeUs  Fargo  I'fildco  Investment  Advisors 
WWMCCS  Informaticm  System 
Wright  Patterson  Air  Force  Base 
Wesyxm  System  Trainer 

World  V^de  Military  Command  and  Control  System 
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The  definiticms  provided  below  are  used  throughout  the  Depattsaeat  of  Defense  (DOD) 
software  community.  Most  of  the  definiticMis  are  from  other  sources.  The  source  ftom 
which  die  definition  originated  is  indicated  in  brackets  at  the  end  of  the  definition,  and 
the  complete  information  about  the  source  is  provided  at  the  end  of  this  glossary.  The 
originator  of  these  definitions  may  periodically  modify  the  definition. 

Activity.  (1)  A  task  or  discrete  stq>  in  a  methodology  performed  to  provide 
management,  technical,  and  support  information  for  decision  making.  [I-CASE]  (2) 
A  unit  of  work  to  be  completed  in  achieving  the  objective  of  a  software  project.  (3) 
The  lowest  level  of  the  hierarchical  decomposition  of  functions  in  the  Enterprise 
Model.  p-CAS^  (4)  A  defined  portion  of  work  within  a  project  diat  typically  has 
a  designated  owner,  entry  requirements,  implementation  requirements,  exit 
requirements,  duration,  and  schedides.  Examples  of  activities  indude  devdqiing  the 
product  spedfication  document,  creating  the  high-levd  design,  coding,  and 
performing  the  system  test. 

Accuracy.  (1)  A  quality  of  that  which  is  free  of  error.  [ISO]  (2)  A  qualitative 
assessment  of  freedom  from  error,  a  high  assessment  correqionding  to  a  small  error. 
PSO]  (3)  A  quantitative  measure  of  the  magnitude  of  error,  preferably  erqnessed  as 
a  fiuK^on  of  Ae  relative  error,  a  hi^  value  of  this  measure  corresponding  to  a  small 
error  [ISO].  (4)  A  quantitative  assessmoit  of  freedom  from  error.  [IEEE] 

Ada.  A  programming  language  developed  on  behalf  of  the  U.S.  DOD  for  use  in 
large,  real-time,  embedded  computer  systems. 

Ada  BINDINGS.  Software  linkages  between  the  Ada  programming  language  and 
other  langu^es.  For  example,  Ada-SQL  bindings  provide  the  means  to  link  Ada 
programs  with  a  Relational  Database  Management  System  (RDBMS)  using  SQL  or 
SQL-like  embedded  instructions. 

Ada  PROORAMMINO  SUPPORT  ENVIRONMENT  (AdaPSE).  A  set  OT  hardware  and 
software  that  supports  all  aspects  of  software  d^dopment  and  maintenance,  including 
project  management  and  configuration  management. 

Ada  REPOSITORY.  A  database  that  contains  reusable  software  componmits  for 
information  system  development.  The  Reusable  Ada  Products  for  Information 
Systems  Devdopment  Program  (RAPID)  was  devdpped  by  the  U.S.  Army  and 
purchased  by  the  Standard  Systems  Center.  [I-CASE] 
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Adaftabilfty.  The  ease  with  which  software  allows  diffoing  system  constraints 
and  user  needs  to  be  satisfied.  [IEEE] 

Alookithm.  a  finite  set  of  well-defined  rules  for  the  solution  of  a  problem  in  a 
finite  number  of  stq)s  (e.g.,  a  comply  specification  of  a  sequence  of  aridimetic 
operations  for  evaluating  sin  x  to  a  given  precisim).  [ISO]  (2)  A  finite  set  of 
well-defined  rules  that  gives  a  sequence  of  operations  for  performing  a  specific  task. 
[IEEE] 


Architecture.  (1)  The  structure  of  components,  their  intenelatimiships,  and 
the  principles  and  guidelines  governing  their  design  and  evolution  over  time.  (2) 
Organization  structure  of  a  system  or  component.  [lEHEJ 

ARCHirECTURAL  DESIGN.  (1)  The  process  of  defining  a  collection  of  hardware 
and  software  components  and  their  interfaces  to  establish  a  framework  for  the 
development  of  a  computer  system.  [IEEE]  (2)  The  result  of  the  architectural  design 
process.  [IEEE] 

Artificial  intelligence,  a  subfield  within  computer  science  concerned  with 
devdoping  technology  to  enable  computers  to  solve  problems  (or  assist  humans  in 
solving  problems)  by  using  explicit  representations  of  knowledge  and  reasoning 
methods  employing  that  knowledge.  [SWTP] 

ATnoBtrrE.  A  piece  of  information  about  an  rnitity  or  relationship.  [I-CASE]. 

Automated  application  generators.  Programs  that  generate  triplication 
programs  from  special  application-oriented  languages.  [SWTP] 

Auixmiated  information  system  (ais).  An  automated  system  in  which  the 
data  stored  will  be  used  in  spontaneous  wa^  that  are  not  fully  predictable  in  advance 
for  obtaining  information. 

AVAiLABiurY.  (1)  The  probability  that  software  will  be  able  to  perform  its 
designated  system  function  when  requited  for  use.  [IEEE]  (2)  The  ratio  of  system 
up-time  to  total  operating  time.  [IEEE]  (3)  The  ability  of  an  item  to  perform  its 
d^gnated  function  when  required  for  use.  [ANSI/ASC^^ 

Baseline.  (1)  A  configuration  identificatitm  document  or  set  of  such  documents 
(r^ardless  of  media)  formally  designed  and  fixed  at  a  spcdfic  time  during  a 
configuration  item’s  life  cycle.  Baselines,  plus  approved  changes  to  those  baselines, 
constitute  the  current  configuration  identification.  [DOD-HDBK-287A]  (2)  A 
qiedfication  or  product  that  has  been  formally  reviewed  and  agreed  upon,  that 
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thereafter  serves  as  the  basis  for  further  development  and  that  can  be  changed  only 
dirough  formal  change  control  procedures.  PEEE]  (3)  A  document  or  set  of  «ich 
documents  formally  designated  and  fixed  at  a  specific  time  during  the  life  cyde  of  a 
configuration  item.  [IEEE] 

BSY-2.  The  distributed  battle  management  system  for  the  SSN-21  submarine  in 
the  U.S.  Navy.  The  system  integrates  sensors  and  wes^ns  and  displays  information. 
[SWTP] 

C2.  See  command  and  control. 

C3I.  See  definitions  of  command  and  control,  communications,  and  intelligence. 

CASE.  Computer-Aided  Software  Engineering  is  the  automation  of  well-defined 
methodologies  that  are  used  in  the  development  and  maintenance  of  software  products. 
These  methodologies  apply  to  nearly  every  process  or  activity  of  a  product 
development  cycle  (e.g.,  project  planning  and  tracking,  product  designing,  coding, 
and  testing). 

CASE  ENVIRONMENT.  A  CASE  environment  is  a  computer  system  consisting  of  a 
fixed  set  of  core  facilities  that  form  the  environment  framework  and  a  set  of  facilities, 
called  tools,  that  supports  software  devdopment  activities.  [I-CASE] 

Certification.  (1)  A  written  guarantee  that  a  system  or  computer  program 
complies  with  its  specified  requirements.  [IEEE]  (2)  A  written  authorization  that 
states  that  a  computer  system  is  secure  and  is  permitted  to  operate  in  a  defined 
environment  with  or  pr^ucing  sensitive  information.  [IEEE]  (3)  The  formal 
demmistration  of  system  acceptability  to  obtain  authorization  for  its  c^)erational  use. 
LihEhj  (4)  The  process  of  confining  that  a  system,  software  subsystem,  or 
computer  program  is  capable  of  satisfying  its  specifi^  requirements  in  an  operational 
environment.  Certification  usually  occurs  in  Ae  field  under  actual  conditions  and  is 
used  to  evaluate  not  only  the  software  itself  but  also  the  ^>ecifications  to  whidi  the 
software  was  construct^.  Certification  extends  the  process  of  verification  and 
validation  to  an  actual  or  simulated  opoational  environment.  [IEEE]  (S)  The 
procedure  and  action  by  a  duly  authorized  body  of  determining,  verifying,  and 
attesting  in  writing  to  the  qualifications  of  personnd,  processes,  procedures,  or  items 
in  accordance  with  applics^le  requirements.  [ANSI/ASQC] 

Chan(X  control  process,  a  defined  process  to  be  followed  when  a  change  to 
a  controlled  document  or  procedure  is  pressed.  A  typical  use  is  to  control  proposed 
dumges  to  product  objectives  or  product  specifications  once  these  documents  have 
been  sqrproved. 
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CUENT'SERVER  ENVIRONMENT.  Defined  most  broadly,  a  client-server 
environment  involves  a  requester  of  a  service  or  services  and  a  ddiverer  of  those 
services.  The  requester  is  normally  a  user  on  a  microcomputer,  whereas  the  deliverer 
is  usually  a  file  server.  Torcmto-based  International  Data  Corp.  analyst  Michael 
O’Neill  defines  client-server  as  networic  architectures  in  which  aqiplications  are  run 
to  some  extent  on  deslctq)  computers  and  servers  provide  additional  services  such  as 
storage,  applications,  communications,  and  printing.  [I-CAS^ 

Coding.  The  act  of  writing  instructions  that  are  immediately  computer 
recognizable  or  can  be  assembled  or  compiled  to  form  computer-recognizable 
instructions.  Within  a  product  development  cycle,  this  activity  follows  the  low-level 
design  activity  and  proves  the  unit  testing  and  Unction  testing  activities. 

Command  and  control.  The  provision  of  communications  and  intelligence  to 
a  properly  designated  commander  of  assigned  forces  for  use  in  the  accomplishment 
of  a  mission.  Command  and  control  functions  are  performed  through  an  arrangement 
of  personnel,  equipment,  communications,  facilities,  and  procedures  employed  by  a 
commander  in  planning,  directing,  coordimuing,  and  controlling  forces  and  operations 
in  the  accomplishment  of  the  mission.  [PUB  1-02] 

C(»ifMERciAL-OFF-THE-SHELF  (COTS)  PRODUCTS.  Items  r^ularly  used  in  the 
course  of  normal  business  operations  for  other  than  (jovemment  purposes  that  (a) 
have  been  sold  or  licensed  to  the  general  public;  (b)  have  not  been  sold  or  licensed, 
but  have  been  offered  for  sale  or  license  to  the  general  public;  (c)  are  not  yet 
available  in  the  commercial  nnartetplace,  but  will  be  available  for  commerc^ 
ddivery  in  a  reasonable  period  of  time;  (d)  are  as  described  in  (a),  (b),  or  (c)  that 
would  require  only  minor  modification  in  ordo’  to  meet  the  requirements  of  the 
procuring  agency.  Minor  modification  means  a  modification  to  a  commercial  item 
that  does  not  alter  the  commercial  item’s  function  or  essential  physical  characteristics. 
[I-CASEI 

CcAiMON  INFORMATION  REPOSITORY.  A  database  that  contains  all  of  the 
information  pertaining  to  systems  development  and  provides  the  means  for  all  tools 
in  the  development  environment  to  share  information  engineering  information. 
D-CASE] 

Communications.  A  method  or  means  of  conveying  information  of  any  kind 
from  one  person  or  place  to  another  [Webster]. 

COMPLEXrry  metrics.  Pertaining  to  any  of  a  set  of  structure-based  metrics  that 
measures  the  degree  to  which  a  system  or  component  has  a  design  or  implementation 
that  is  difficult  to  understand  and  verify  (See  SoftwareComplexity).  The  more 
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oomitoi  a  program,  Ae  more  likely  it  will  contain  oiors.  Examples  of  complexity 
metrics  are  module  size,  Halstead’s  Software  Science  Maries,  McCabe's  cyclomatic 
number,  and  McClure’s  contnd  variable  complexity.  [I-CASE] 

CmiPONENT.  A  portion  of  a  software  system  that  contains  oat  logical  subdivision 
of  the  tystem.  A  given  software  system  may  be  seen  as  composed  of  its  various 
components.  [SWTP] 

Computer  software  conhouration  item  (csci).  a  configuration  item  for 
computer  software.  [DOD-STD-2167A] 

Concept  of  operations  (conops).  Detailed  narrative  description  of  a  targeted 
area’s  functiems  and  all  of  their  interrdationships  during  peacetime,  exercise,  crisis, 
and  wartime. 

Conceptual  data  model.  Identiftcation  and  description  of  all  of  the  entities 
and  relationships  diat  support  the  key  areas,  tasks,  and  activities  defined  in  the 
Enterprise  Model  of  the  targeted  area.  These  entities  and  rdationships  define  the 
inherent  structure  of  information  within  the  enterprise.  p-CASE] 

Configuration  control.  The  systematic  evaluation,  sqrproval  or  disapproval, 
and  implementation  of  all  approved  changes  in  the  configuration  of  a  configuration 
item  ato  formal  establishment  of  its  configuration  identification.  p-CASE] 

Configuration  item.  Hardware  or  software,  or  an  aggr^ate  of  both,  which  is 
designated  by  the  contracting  a^cy  (or  project  configuration  manager)  for 
configuratitm  management.  p>OD-HDBK-287A] 

Configuration  identification.  Die  rqqproved  or  conditionally  ayiproved 
tedinical  documentation  for  a  configuration  item  as  set  forth  in  specifications, 
drawings,  associated  lists,  and  documoits  referoiced  thernn.  pX)D-HDBK-287  \] 

Configuration  management.  (1)  Die  process  of  identifying  and  defining  the 
configuration  items  in  a  system,  controlling  the  release  and  change  of  diese  items 
throughout  the  system  life  cycle,  recording  and  reporting  the  status  of  configuration 
items  and  change  requests,  and  verifying  the  completeness  and  correctness  of 
configuration  items.  pEEE]  (2)  A  discipline  applying  technical  and  administrative 
direction  and  surveillance  to  (a)  identify  and  document  the  functional  and  jrfiysical 
characteristics  of  a  configuration  item,  (b)  control  changes  to  those  characteristics, 
and  (c)  record  and  report  change  processing  and  implementation  status.  PX)D-STD 
480A] 
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CONFiGUltATlON  MANAGEMENT  PLAN  (CMP).  The  (^onfiguntioii  Management 
Plan  defines  the  implementation  Onclu^g  policies  and  m^hods)  of  configuration 
management  rai  a  particular  progi^prcgect.  [DOD-HDBK-287A] 

Contract  change  proposal,  a  formal  priced  document  also  referred  to  as 
"Task  Change  Proposal  (TCP)*  used  to  propose  changes  to  the  scope  of  work  of  the 
contract.  It  is  different  from  an  Engineering  Change  Proposal  (ECP)  in  that  it  does 
not  affect  specifications  or  drawing  requirements.  It  may  be  used  to  propose  changes 
to  contractual  plans,  the  Statement  of  Work  (SOW),  Contract  Data  Requirements  List 
(CDRL),  and  others.  [I-CASE] 

Contract  data  requirements  list  (cdrl).  Identifies  the  name  of  the  item 
to  be  delivered,  the  date  it  is  to  be  delivered,  and  a  Data  Item  Description  (DID). 

Contractor.  An  individual,  partnership,  company,  corporation,  or  association 
diat  has  a  contract  with  the  contracting  agency  (Government)  for  the  design, 
development,  maintenance,  modification,  or  supply  of  configuration  items  and 
services  under  the  terms  of  a  contract.  A  Government  agoicy  performing  any  of  the 
above  actions  is  considered  a  "contractor*  for  configuration  management  purposes. 
[DOD<HDBK-287A] 

Cost  analysis.  (1)  The  act  of  breaking  down  a  cost  summary  into  its 
constituents*  and  studying  and  reporting  on  each  factor.  (2)  The  comparison  of  costs 
(as  of  a  standard  with  actual  or  for  a  given  period  with  another)  for  the  purpose  of 
disclosing  and  rqwrting  on  conditions  subject  to  improvement.  [WEBSTER] 

Critical  path.  The  collection  of  work  activities  in  a  produa  devdopment  cycle 
that  ate  neck-to-neck  with  one  another  and  define  the  longest  duration  for  a  project. 

Critical  real-time  system.  A  system  in  which  failure  to  meet  a  deadline  has 
an  impact  on  safety  or  could  cause  large  financial,  social,  or  military  losses.  [SWTP] 

Critical  requirements.  Any  or  all  of  a  wide  range  of  chaiactoristics  the 
absence  or  diminished  presence  of  which  in  a  system  can  result  in  serious 
consequences.  [SWTP] 

Data.  A  rqnesentation  of  foots,  concepts,  or  instructicms  in  a  formalized  manner 
suitable  for  communication,  interpretation,  or  processing  by  human  or  automatic 
means.  Any  rqnesentations  such  as  charactos  or  analog  quantities  to  which  meaning 
is  or  might  be  assigned.  [PUB  1-02] 
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Databases.  Electronic  repositories  of  information  accessible  tfirough  a  query 
language  intei^'e.  [SWTP] 

Database  management  system  (i»ms).  An  int^rated  software  system  that 
has  facilities  for  defining  the  logicd  and  physical  structure  of  data  in  a  database  and 
for  accessing,  entering,  and  deleting  data.  [DOC] 

Data  flow  diagram.  A  graphical  rq>resentation  of  the  various  processes  and 
flows  of  information  that  make  up  a  function.  [I-CASE] 

Data  integrity.  Confidence  that  the  data  a  software  system  is  using  or 
producing  is  right,  data  values  being  produced  are  right,  and  q)urious  values  are  not 
being  inserted  into  the  system  from  external  sources.  [SWTP] 

Data  item  description  (did).  A  document  that  contains  details  and  reference 
standards  with  which  a  deliveiable  must  comply.  [I-CASE] 

Data  modeung.  The  process  of  identifying  an  supplication’s  data  elements,  data 
structures,  and  file  format  structures.  This  includes  ddineating  the  relationships 
between  data  elements,  generally  with  entity-relationship  diagrams.  [I-CASE] 

Data  repositories.  Refers  to  the  dynamic  data  that  are  used  during  the 
devdopment  process.  Repositories  will  contain  a  broad  range  of  fine  and  coarse  grain 
project  information.  P-CASE] 

Design.  The  process  of  defining  the  architecture,  components,  interfaces,  and 
other  characteristics  of  a  system  or  component;  often  referred  to  as  the  Design  Phase. 
P-CASE] 

Design  fault.  A  fault  committed  during  the  design  of  a  software  system  or 
during  a  subsequent  modification  of  the  design.  [SWTP] 

Develo»4ENT  environment.  The  hardware  and  software  platforms  that  will 
be  used  to  support  software  devdopment  activities.  p-CASE] 

Distributed  processing.  The  organization  of  processing  to  be  carried  out  <m  a 
distributed  system  (see  distributed  system).  Each  process  is  free  to  process  local  data 
and  make  local  decisions.  The  processes  exchange  information  with  each  other  over 
a  data  communication  network  to  process  data  or  to  read  decisions  that  affect  multiple 
processes.  [DOC]  Running  a  program  on  several  diffment  machines.  [SWTP] 
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Dbtrduted  system.  Any  system  in  which  a  number  of  independent 
interconnected  computers  can  cotqierate.  [DOC] 

Document.  Any  subset  of  technical  data  that,  packaged  for  ddivery  on  a  single 
medium,  meets  the  format,  content,  consistency,  and  completeness  requirements  of 
a  unified  control  specification  whether  delivered  in  hard  copy  or  digital  fbim.  A 
document  is  a  self-contained  body  of  engineering  data  that  supports,  alone  or  with 
(rther  documents,  an  engineering  or  maintoiance  function.  [I-CASE] 

DCAfAlN.  A  set  of  current  and  future  sq)plications  that  performs  common  sets  of 
functions.  DOD  software  domains  include  avionics,  vehicle  control,  C3I,  and 
logistics.  [SWTP] 

Domain  analysis.  The  process  of  identifying,  collecting,  oiganizing,  and 
representing  the  relevant  information  in  a  domain.  The  process  is  based  <m  the  study 
of  existing  systems  and  their  development  histories,  knowledge  ciqNured  fiom  domain 
experts,  underlying  theory,  and  emerging  technology  within  the  domain.  [SWTP] 

Dcaaain  KNOWLEDGE.  (1)  Knowledge  about  the  objects,  concq>ts,  and 
relationships  of  a  particular  domain.  [SWTP]  (2)  The  set  of  data  and  business  rules 
iq)plicable  to  a  product  sq>plication  or  functional  area.  [I-CASE] 

Dcmiain-specific.  Concerned  with  the  objects,  concepts,  and  relationships  of  a 
particular  domain.  [SWTP] 

Embedded  computer  system,  a  computer  system  that  is  integral  to  a  larger 
system  the  primary  purpose  of  which  is  not  computational,  (e.g.,  a  computer  system 
in  a  wesqwn,  airc^,  command  and  control,  or  rsq)id  transit  system).  PEEE] 

Embedded  software.  Software  for  an  embedded  computer  system.  [IEEE) 

Enterprise  model.  (1)  A  hierarchical  description  of  key  areas  of  functionality, 
their  subordinate  tasks,  and  qiecific  activities  identified  in  the  ConcqH  of  Opeiatims 
(CONOPS).  (2)  A  high-level  model  of  an  organization’s  information  ardiitecture  that 
consists  of  a  fimction  model  and  a  data  modd.  [ELG]  (3)  A  description  of  the 
(entity)  types,  fimctions,  and  processes.  [MARTIN] 

Entity.  (I)  A  distinct  thing  (such  as  a  parson,  place,  thing,  or  event)  of  interest 
to  the  enterprise  about  which  data  are  stored.  It  holds  meaning  in  context  with  otha 
entities  in  die  enterprise.  (2)  Person,  place,  diing,  concept,  event,  or  activity  about 
which  an  organization  wishes  to  keep  information.  [DODI^ 
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Environment.  (1)  Collection  of  hardware  and  software  enveloped  in  a  jNocess 
to  engineer  software.  (2)  Everything  that  supports  a  system  or  the  performance  of  a 
fimction.  [ELG]  (3)  The  conditions  that  affect  the  performance  of  a  system  or 
function.  [ELG]  (4)  That  part  of  the  real  world  that  contains  the  users  that  exchange 
messages  with  an  information  system.  [ELG] 

Environment  framework.  The  core  set  of  facilities  in  a  CASE  environment 
that  provides  necessary  control,  data,  presentation,  and  communicaticm  services  for 
tools  executing  in  that  environment.  P-CASE] 

Error.  (1)  A  manifestation  of  a  fault;  data  (usually  involving  the  system  state) 
that  prepuce  a  failure  when  processed  by  the  system.  (2)  A  discrqaancy  between  a 
computed,  observed,  or  measured  value  or  condition  and  the  true,  specified,  or 
theoretically  correct  value  or  condition.  [IEEE] 

Evolutionary  prototyping.  An  approach  to  software  development  where  a 
user’s  system  is  established  using  rapid  prototyping  techniques,  then  is  updated  and 
maintained  as  required.  [I-CASE] 

Exception.  An  event  that  causes  suspension  of  normal  program  execution. 
[IEEE] 

Expert  systems.  Computer  programs  built  for  commercial  sqiplicadon  by  using 
the  programming  techniques  of  Artificial  Intelligence  (AI),  espedkly  those  techniques 
developed  for  problem  solving,  and  involving  the  use  of  appropriate  information 
acquired  previously  from  human  experts.  [DCK!] 

Failure,  (l)  The  result  of  a  system  or  component  not  performing  a  required 
function  within  specified  constraints.  (2)  The  termination  of  the  ability  of  a  fimctional 
unit  to  perform  its  required  function.  (3)  The  inability  of  a  system  or  system 
component  to  perform  a  required  function  within  specified  limits  (may  be  produced 
when  a  fault  is  encountered).  (4)  A  departure  of  program  operation  from  program 
requirements.  [IEEE] 

Failure  rate.  (1)  The  ratio  of  the  number  of  failures  to  a  given  unit  of 
measure  (e.g.,  failures  per  unit  of  time,  failures  per  number  of  transactions,  failures 
per  number  of  computer  runs).  (2)  In  reliability  modeling,  the  ratio  of  the  number 
of  fiulures  of  a  given  category  or  severity  to  a  given  period  of  time  (e.g.,  failures  per 
second  of  execution  time,  failures  per  month).  [lE^] 

Fault,  (l)  An  accidental  condition  that  causes  a  functional  unit  to  fail  to 
perform  its  required  function.  (2)  A  manifestation  of  an  error  in  software.  A  fault, 
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if  enomintered,  may  cause  a  failure.  (lEE^  (3)  A  discrepancy  in  an  automated 
systmn  encountered  during  testing.  [I-CASE) 

Fault  avoidance.  (1)  Action  that  reduces  the  likdihood  of  a  fiuilt  during 
system  operation,  such  as  isolating  or  rq>lacing  system  components  with  a  high 
predicted  probability  of  failure  based  on  enoT  reports  or  stress  data.  [SWTP]  (2) 
The  elimination  of  faults  by  careful  and  conservative  design  and  construction 
practices.  [SWTP] 

Fault  prevention.  The  elimination  of  faults  by  careful  and  crmservative  design 
and  omstruction  practices.  [SWTP] 

Fault  recovery.  The  attempt  to  bring  a  system  to  a  state  accq>table  for 
continued  operation.  [SWTP] 

Fault  tolerance.  The  built-in  cs^}acity  of  a  system  to  provide  continued 
correct  execution  despite  faults  or  failures  of  hardware  or  software  components. 
[EEEE] 

Fault-tolerant  software.  Software  that  includes  fimctions  for  detecting, 
identifying,  confining,  and/or  recovering  from  feults  to  create  a  fault-tolerant  system. 
[SWTP] 

Formal  qualification  test,  a  test  conducted  in  accordance  with  formally 
^>proved  test  plans  and  procedures  and  witnessed  by  Government  rq)resentatives  to 
show  that  the  integrated  hardware  and  software  satisfy  spedfic  requirements. 
P-CASE] 

Forward  engineering.  (1)  The  process  of  gmierating  the  design  from  the 
requirements  and  generating  the  code  from  the  design.  (2)  The  traditional  process  of 
moving  from  high-level  abstractions  and  logical,  implementation-indq}endent  designs 
to  the  physical  implementation  of  a  system.  [CHK] 

Frameworks.  General  designs  or  architectures  for  systems  that  can  be 
customized  or  specialized  for  particular  applications.  [SWTP] 

Function.  An  action  that  a  product  is  capable  of  performing.  For  example, 
functions  for  a  word  processor  might  be  define  margins,  define  page  length,  set  tabs, 
change  font  for  all  section  headings,  search  for  words  and  phrases,  and  automatic 
document  save. 
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Functional  requirement.  a  requirement  that  q)ecifies  a  function  that  a 
system  or  system  component  must  be  capable  of  performing.  [IEEE] 

Function  test.  The  testing  of  each  product  function  across  one  or  more 
modules.  Some  amount  of  scaffolding  is  typically  required  to  perform  this  test. 
P-CASE] 

Government-furnished  equipment  (gfe).  Equipment  furnished  by  the  U.S. 
Government.  [I-CASE] 

Government  open  systems  interconnection  profile  (oosp).  a  Federal 
Information  Processing  Standards  Publication  (FIPS  PUB)  that  defiii^  a  common  stt 
of  data  communication  protocols  that  enable  systems  developed  by  different  vendors 
to  interoperate  and  enable  users  of  different  applications  on  these  systems  to  exchange 
information.  [I-CASE] 

Gosip-compliant.  Computer  network  protocols  that  are  in  compliance  with 
FIPS  PUB  146,  "Government  Open  Systems  Interconnection  Profile.*  p-CASE] 

Graceful  degradation.  The  ability  of  a  system  to  shed  noncritical 
functionality  to  accomplish  critical  functions  within  their  deadlines  during  failures. 
[SWTP] 

Hard  real-time  system.  A  system  that  must  completely  service  each  task  and 
produce  results  within  specified  time  intervals  (i.e.,  a  system  that  must  respond  to 
hard  deadlines).  [SWTP] 

Hardware.  Physical  equipment  used  in  data  processing,  as  opposed  to 
computer  programs,  procedures,  rules,  and  associated  documentation.  [lEE^ 

Heterogeneous  network,  a  network  of  different  host  computers,  such  as 
those  of  different  manufacturers.  p-CASE] 

Heterogeneous  processors.  Processors  of  different  types  that  use  different 
organization  (e.g.,  shared  memory,  arrays)  or  architecture  Reduced  Instruction  Set 
Computer  [RISC],  Complete  Instruction  Set  Computer  [CISC]).  Includes  also 
processors  built  by  different  manufacturers  (e.g..  Digital  Equipment  Corporation, 
Sun,  IBM).  [SWTP] 

High  assurance  software.  Software  for  which  there  is  compelling  evidence 
that  the  computer  system  will  respond  properly  under  all  circumstances  in  the  context 
of  its  application.  [SWTP] 
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High-level  design.  The  level  of  design  required  to  understand  how  the 
components  of  a  product  will  technically  work  with  one  another  and  with  the 
surrounding  hardware  and  software  environment  in  which  the  components  must 
operate.  This  design  identifies  the  components  that  make  up  the  product,  defines  the 
functional  mission  for  each  component,  and  defines  the  interface  across  these 
components  and  externally  to  the  operating  environment. 

Hypertext.  A  method  of  organizing  tect  to  enable  the  user  to  browse  through 
the  text  in  any  order  and  examine  any  portion  at  any  time  without  having  to  read  the 
text  from  start  to  end.  [SWTP] 

I-CASE.  Integrated  Computer  Aided  Software  Engineering  components  that  span 
the  full  software  development  life  cycle.  p-CASE] 

I-CASE  ENVIRONMENT.  Automated  software  development  environment  that 
includes  a  Software  Engineering  Environment  (SEE),  an  Operational  Test 
Environment  (OTE),  and  an  Application  Execution  Environment  (AEE).  It  will 
support  and  be  used  by  DOD  organizations  responsible  for  development, 
modernization,  and  maintenance  of  AISs.  p-CASE] 

IEEE  FUTUREBUS-f.  A  Computer  backplane  standard  adopted  by  the  U.S.  Navy 
for  its  next-generation  computing  systems.  (SWTP] 

Implementation  phase.  That  portion  of  a  system’s  life  cycle  when  the  system 
reaches  its  initial  operational  capability.  p-CASE| 

Independent  verihcation  and  validation  (iv&v).  (1)  Verification  and 

validation  of  a  software  product  by  an  organization  that  is  both  technically  and 
managerially  separate  from  the  organization  responsible  for  developing  the  product. 
[IEEE]  (2)  Verification  and  validation  of  a  software  product  by  individuals  or  groups 
other  than  those  who  performed  the  original  design  but  who  may  be  from  the  same 
organization.  The  degree  of  independence  must  be  a  function  of  the  importance  of 
the  software.  PEEE]  (3)  An  independent  review  of  the  software  product  for 
functional  effectiveness  and  technical  sufficimcy. 

Informal  test.  The  testing  performed  on  a  product  that  is  typically  conducted 
in  a  loosely  controlled  environment  and  is  performed  by  the  programmers  who 
developed  the  code  to  be  tested.  Both  the  unit  test  and  function  test  are  considered 
informal  test  activities.  Some  amount  of  scaffolding  is  typically  required  during  the 
informal  test  period. 
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Information  engineering.  The  science  of  analyzing  value-added  information 
usage  and  organizing  heterogeneous  information  (e.g.,  hard  copy,  ASCII,  graphics, 
voice,  video,  structured  files)  so  that  it  is  stored,  processed,  and  retrieved  in  a  form 
useful  to  each  level  of  decision  making  within  an  organization.  [SWTP] 

Information  hidino.  A  design  concept  put  forward  by  Pamas  [Pamas  1971, 
1972].  Modules  most  likely  to  be  changed  in  the  future  should  be  designed  in  such 
a  way  that  those  design  decisions  are  hidden  from  other  modules.  Therefore,  if  a 
change  has  to  be  made  in  the  future,  such  a  change  is  localized  to  one  specific 
module.  [I-CASE] 

Information  repository.  Encompasses  the  csq)abilities  currently  found  in 
multiple  types  of  products  (i.e. ,  data  repository,  repository  manager,  library  manager, 
and  reuse  library).  [I-CASE] 

Information  resource  dictionary  system  (irds).  a  computer  software 
system  that  provides  facilities  to  control,  describe,  protect,  document,  and  facilitate 
use  of  an  installation’s  information  resources.  [I-CASE] 

Information  systems  engineering.  The  process  of  defming  requirements  for 
databases,  applications,  and  technical  services.  [I-CASE] 

Inspection;  Examination  of  an  activity  by  a  group  of  pet^le,  typically  peers,  to 
identify  and  remove  defects  and  problems  from  a  product. 

Integrated  logistics  support  (ils).  A  composite  of  the  elements  necessary 
to  assure  the  effective  and  economical  support  of  a  system  or  equipment  at  all  levels 
of  maintenance  for  its  programmed  life  cycle.  [I-CASE] 

Integration.  The  process  of  combining  software  elements,  hardware  elements, 
or  both  into  an  overall  system.  [IEEE] 

Integration  services.  Services  that  provide  for  integration  of  components 
across  the  life  cycle  of  software  applications,  ftom  concept  development  through 
decommissioning  or  replacement.  p-CASE] 

Interface.  The  supporting  hardware  and  software  through  which  dialogue  takes 
place.  [SWTP] 
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Knowledge.  (l)  Computer  data  structures  designed  to  cs^pture  or  encode 
knowledge  in  structural  forms  that  can  be  easily  manipulated  by  leascming  processes. 
[SWTP]  (2)  What  a  person  or  computer  must  know  to  perform  a  given  task. 
[SWTP] 

Knowledge  representation.  Computer  data  structures  rfi^gncd  to  capture 
or  encode  knowledge  in  structural  forms  that  can  be  easily  manipulated  by  reasoning 
processes.  [SWTP] 

Library  manager.  Performs  version  control  and  configuration  management  on 
larger  grain  objects  such  as  source  code,  object  modules,  and  documentation. 
[I-CASE] 

Life  cycle.  (1)  The  period  of  time  ^compassing  the  life  of  an  automated 
system.  (2)  The  period  of  time  that  begins  when  a  system  is  conceived  and  ends 
when  the  product  is  no  longer  available  for  use.  [BEEE] 

Life*cycle  model,  a  model  of  the  software  life  cycle  describing  the  of 
steps  or  phases  through  which  the  software  progresses  (e.g..  Code  and  Fix,  Waterfall, 
Rapid  Prototyping,  and  Incremental  Release).  P-CASE] 

Low-level  design,  a  term  representing  two  levels  of  design:  (1)  The  design 
required  to  understand  how  the  modules  within  each  component  will  technically  work 
with  one  another.  This  design  identifies  the  modules  that  make  up  each  component, 
the  functional  mission  of  each  module,  and  the  interface  across  these  modules.  (2) 
The  design  required  to  define  the  design  within  each  of  the  many  modules  that  may 
constitute  each  component.  This  design  level  identiftes  each  programming  decision 
path  within  each  mc^ule  and  is  the  lowest  level  of  design  before  coding. 

Maintenance  support.  Modification  of  a  product  after  delivery  to  correct 
faults,  to  improve  performance  or  other  attributes,  or  to  adapt  the  product  to  a 
changed  environment.  PEEE] 

Measurement.  The  act  or  process  of  measuring  something  to  ascertain  the 
quantity,  mass,  extent,  or  degree  in  terms  of  a  standard  unit  or  fixed  amount,  usually 
by  means  of  an  instrument  or  container  marked  off  in  the  units.  [WEBSTER] 

Megaprogramming.  (l)  Computer  systems  design  and  implementation  using 
preexisting  software  modules  of  known  functionality  as  primitives  [SWTP].  (2)  The 
development  of  software  by  composing  components  rather  than  individual  lines  of 
code.  [SWTP] 


156 


Department  of  the  Navy 


Glossary 


Methodology.  (1)  The  way  the  group  activities  within  a  process  are 
accomplished;  the  approach  to  solving  the  pit^lem;  a  body  of  methods,  rules,  and 
postulates  employed  by  a  discipline.  (2)  A  general  iMosoi^y  for  carrying  out  a 
process;  composed  of  procedures,  principles,  and  practices.  [STARS] 

Metrics.  (1)  Numerical  data  collected  during  the  software  production  process 
and  used  to  compute  measures  of  quality,  productivity,  and  performance  of  software 
products,  development  tools,  methods,  techniques,  and  processes.  (2)  A  composite 
of  one  or  more  measures  used  to  understand  a  process.  [BOEING]  (3)  Those 
measurements  established  for  each  step  in  the  software  engineering  process  that  are 
used  to  determine  its  effectiveness.  The  metrics  define  the  results  of  each  process 
stage  and  relate  them  to  resources  expended,  errors  introduced,  errors  removed,  and 
various  coverage,  efficiency,  and  productivity  indicators.  [I-CASE] 

Modernization.  The  implementation  of  new  techniques  or  technology. 
Through  modernization,  the  Government  seeks  to  redesign  all  antiquated  software 
systems  into  Ada  applications  and  implement  them  as  such.  [I>CASE] 

Modification.  The  process  of  changing  existing  software  to  support  the  evolving 
changes  in  design  specifications.  [DOD-HDBK-287A] 

Module.  (1)  Software  components  required  to  support  the  products  and 
a^lications  within  the  operational  constraints  of  the  environment.  (2)  Code  that 
represents  part  of  a  function,  a  single  function,  or  more  than  one  function.  A  module 
is  code  that  can  be  independently  compiled.  One  or  more  modules  usually  make  up 
a  component.  [I-CAS^ 

Network  services.  Services  to  support  distributed  applications  requiring  data 
access  and  applications  interoperability  in  heterogeneous  or  homogeneous  networked 
ravironments.  [I-CASE] 

Object.  An  entity  that  is  characterized  by  the  operations  that  can  be  sqjplied  on 
or  by  the  entity.  [I-CASE] 

Object  management  services.  Services  that  manage  an  information 
repository  that  stores  information  supporting  software  development  of  program  or 
project  data  across  all  components  within  the  environment.  [I-CASE] 

Object  management  system,  a  data  management  system  the  data  of  which 
are  characterized  by  object  descriptions.  [SWTP] 
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Object-orienteo  design,  a  method  of  design  encompassing  the  process  of 
object-oriented  decomposition  and  a  notation  for  dqricting  both  logical  and  physical 
as  well  as  static  and  dynamic  models  of  the  system  under  design;  q)ecifiadly,  this 
notation  includes  class  diagrams,  object  diagrams,  module  diagrams,  and  process 
diagrams. 

Open  systems.  Refers  to  a  combination  of  standards.  Specifically,  open  systems 
is  a  combination  of  the  standards  as  deHned  in  the  National  Institute  of  Standards  and 
Technology  (NIST)  Application  Portability  Profile  (APP)  for  POSIX  and  XPG3.  This 
is  applicable  to  both  hardware  and  softw^.  [I-CASE] 

Open  systems  architecture  (osa).  An  architecture  that  implements 

international  standard  protocols.  [I-CASE] 

Open  systems  environment  (ose).  Computing,  communications,  and 

^^lication  software  products  that  have  vendor-independent  interfaces.  [ELG] 

Operational  test  environment  (ote).  The  primary  purpose  of  the  I-CASE 
OTE  is  to  test  applications  generated  by  the  I-CASE  SEE.  This  test  environment  is 
used  to  test  application  functionality  and  evaluate  performance  of  the  application  in 
the  I-CASE  SEE  (target  environment).  Hie  I-CASE  OTE  supports  compilation  and 
testing  of  application  source  code  developed  and  maintained  in  the  SEE  and  includes 
nm-time  components  required  for  the  applications  to  execute  on  their  open  system 
hardware  platforms.  [I-CASE] 

Phase.  A  defined  portion  of  a  product  development  cycle.  The  portions  defined 
as  phases  are  arbitrary  and  are  usually  determine  by  the  group  that  plans  the  project. 
AIm,  a  subset  of  activities  that  make  up  a  major  activity.  For  example,  a  project 
document  review  cycle  is  composed  of  five  phases:  preparation,  review,  update, 
^proval,  and  information. 

Physical  data  model.  Representation  of  the  technically  indepoident  data 
requirements  in  a  physical  environment  in  hardware,  software,  and  network 
configurations  as  alternative  methods  of  implementing  the  conceptual  design  in  a 
"functional”  system  or  representing  them  in  the  constraints  of  an  existing  physical 
environment.  [I-CASE] 

PoRTABiLFTY.  The  ease  with  which  software  can  be  transferred  from  one 
computer  system  or  environment  to  another.  [IEEE] 

Portable  operating  system  interface  (posdc).  An  IEEE  standard  that 
defines  a  C  language  source  interface  to  an  operating  system  environment.  [I-CASE] 
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PROCE5:  (1)  A  set  of  actions,  tasks,  and  procedures  that,  whan  performed  or 

executed,  obtains  a  specific  goal  or  objective.  (2)  A  series  of  actions,  changes  or 
functions  that  achieve  an  end  or  result.  (3)  A  model  for  accomplishing  an  objective. 
[BOEING]  (4)  The  logical  organization  of  people,  machines,  tools,  methods,  and 
procedures  into  work  activities  designed  to  pn^uce  a  specified  aid  result  (work 
product).  The  term  software  process  refers  to  processes  that  are  intrinsic  to 
itevelt^ing  and  evolving  software  systems.  [SWTP]  (5)  The  grouping  of  activities; 
what  is  to  be  done  in  the  development  of  software,  the  sequence  of  phases,  tasks,  and 
activities  required.  (6)  The  manner  in  which  a  software  development  project,  or  any 
of  its  many  integral  parts,  is  planned,  developed,  or  tracked.  For  example,  the 
method  of  logging  in  a  problem  and  tracking  that  problem  to  a  satisfactory  closure  is 
defined  as  a  process.  [I-CASE] 

Process  definition.  An  explanation  of  the  meaning  of  a  specific  software 
process  (e.g.,  the  software  quality  assurance  process).  [SWTP] 

Process  management.  The  management  of  the  creation  and  maintenance  of 
software  process  definitions  before  and  during  their  use  in  building  or  maintaining 
systems  or  families  of  systems.  [SWTP] 

Process  management  services.  Services  that  provide  the  mechanism  to 
manage  lifecycle  processes  as  described  by  the  I-CASE  Software  Process  Model. 
P-CASE] 

Process  model.  One  specific  embodiment  of  a  software  process  architecture 
(i.e.,  an  embodiment  of  a  set  of  software  process  definitions  configured  to  create  or 
maintain  a  system  or  family  of  systems).  [SWTP] 

Process  modeling.  To  make  or  conform  to  a  chosen  framework  for  identifying, 
defining,  and  organizing  th.;  business  strategies,  rules,  and  processes  need^  to 
manage  and  support  the  way  an  organization  does  or  wants  to  do  business.  p-CASE] 

Product,  a  software  package,  consisting  of  code  and  documentation,  that  is 
eventually  delivered  to  a  customer.  In  a  more  global  sense,  the  definition  of  product 
also  includes  the  product  support  materials  related  to  activities  such  as  marke^g  and 
maintenance. 

Product  baseline.  The  initially  or  conditionally  approved  product 
configuration  identification.  P-CASE] 

Product  development  cycle.  The  sequence  of  activities  followed  in 
develc^ing  a  product.  A  product  development  cycle  covers  a  wide  range  of  activities 
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tint  typically  include  creating  the  product  objectives  and  the  product  specifications  and 
designing,  coding,  testing  and  packaging  the  final  product  for  delivery  to  customers. 

Product  specifications.  A  document  that  details  precisely  what  the  user  will 
receive  and  use  when  the  completed  product  is  made  available.  Every  function, 
command,  screen,  prompt,  and  so  on  is  documented  in  the  ^lecification  so  that  all 
participants  involved  in  the  product  development  cycle  know  the  product  they  are  to 
build,  test,  document,  and  support. 

Program.  The  code  portion  of  a  product  or  test  case  or  a  collection  of 
components  linked  together. 

Program  or  project  management.  Provides  the  necessary  planning, 
organization,  staffing,  direction,  and  control  for  the  orderly  development  or 
acquisition  of  a  software  product.  [I*CASE] 

Proorakiming  language.  An  artificial  language  designed  to  generate  or 
express  programs.  PEEE] 

Project.  The  combined  resources  (i.e.,  people,  computers,  and  materials), 
processes,  and  activities  dedicated  to  building  and  delivering  a  product.  Also,  a 
group  of  people,  typically  from  two  or  more  organizations,  that  is  working  on  the 
same  product. 

Prototype.  (1)  An  experimental  model  for  a  system  on  which  decisions  for  later 
versions  are  based  or  judged.  [SWTP]  (2)  A  fonctional  model  of  a  target  system, 
suitable  for  evaluation  of  design,  performance,  and  product  potential  or  an  instance 
of  a  software  version  that  does  not  exhibit  all  of  the  properties  of  the  final  system; 
usually  lacking  in  terms  c  <  ruactional  or  performance  attributes.  [DOD-HDBK-287A] 
(3)  A  preliminary  type,  /  *  or  instance  of  a  system  that  serves  as  a  model  for  later 
stages  or  for  the  fiiud,  complete  version  of  the  system.  [lEE^  (4)  An  early  running 
model  of  a  product  the  primary  purpose  of  which  is  usually  to  experiment  with, 
demonstrate,  or  prove  the  feasibility  of  a  concqjt. 

Proof-of-concept.  a  type  of  demonstration  generating  evidence  that  the 
concqjt  is  effective.  [SWTP] 

Provably  secure  software  system,  a  software  system  for  which  it  can  be 
proved  that  the  software  has  a  level  of  assurance  th^  the  system  can  enforce  a 
specific  security  policy  and  that  integrity,  avsdlability,  and  liveness  are  also  assured. 
[SWTP] 
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Qualification  testino.  Product  testing  that  demonstrates  that  the  products 
satisfies  all  "MINIMUM"  requirements  in  the  current  version  of  the  I-CASE 
Spedfication  Requirements  and  that  occurs,  at  the  Government’s  option,  as  a 
precondition  for  the  product  baseline.  [I-CASE] 

Quality.  Conformance  to  requirements.  Once  the  product  and  process 
requirements  have  been  defined,  the  quality  can  be  measured  for  compliance. 

Quauty  assurance  (qa).  (1)  A  planned  and  systematic  pattern  of  all  actions 

necessary  to  provide  adequate  confidence  that  the  item  or  product  conforms  to 
established  technical  requirements.  [lEEEl  O)  Methodologies  and  techniques  used 
to  perform  critical  evaluation  of  computer  systems  to  ensure  release  of  high-quality 
prt^ucts.  p-CASE] 

Quality  assurance  group.  People  assigned  to  perform  an  "outside 
check-and-balance"  role  of  ensuring  that  a  product  is  being  developed  according  to 
an  acceptable  process. 

Quality  assurance  plan.  A  document  that  can  be  used  to  define,  track,  and 
measure  both  product  and  process  quality  goals  throughout  the  product  developmrat 
cycle. 

Rapid  prototyping.  (1)  The  process  of  building  executable  versions  of  partially 
constructed  systems  to  allow  early  observation  and  understanding  of  system  bc^vior, 
especially  its  interface.  [SWTP]  (2)  Hie  use  of  an  sq^lication  generator  and/or 
ntmprocedural  Fourth  Generation  Languages  (4GLs)  to  quicldy  develop  a  prototype 
of  tey  portions  of  the  user’s  desired  capability.  p-CASE] 

Real-time  software  system,  a  software  system  that  satisfies  critical  timing 
requirements.  The  correctness  of  the  software  dqiends  on  the  results  of  computation 
and  on  the  time  at  which  the  results  are  produced.  [SWTP] 

Reengineering.  (1)  The  examination  and  alteration  of  a  subject  system  to 
reconstitute  it  in  a  new  form  and  the  subsequent  implementation  of  the  new  form; 
generally  includes  some  form  of  reverse  engineering  (to  achieve  a  more  abstract 
description)  followed  by  some  form  of  forward  engineering  or  restructuring.  [CHIK, 
I-CASE]  (2)  Redesign  and  developmrat  of  a  system  and  its  data  structures  from  an 
existing  baseline  to  improve  its  functionality  or  configuration.  These  can  be  based 
on  reverse  engineering  products  or  upon  ^sting  documentation  and  design  documents 
or  by  other  systems  analysis  methods.  [DODM,  I-CASE]  (3)  The  process  of 
examining  an  existing  software  system  (program)  and/or  modifying  it  with  the  aid  of 
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automated  tools  to  improve  its  future  maintainability,  upgrade  its  technology,  extend 
its  life  expectancy,  ci^ture  its  components  in  a  repository  where  CASE  tools  can  be 
used  to  support  it,  and  increase  maintenance  productivity.  [MCC,  I-CASl^ 

Reference  model.  a  conceptual  frameworic  that  helps  to  describe  and 
compare  systems.  As  used  here,  it  describes  the  set  of  services  an  environment 
provides,  but  not  the  architecture  of  how  such  services  are  to  be  provided.  p-CASE] 

Regression  testing.  A  software  function  that  performs  the  rerunning  of  tests 
to  detect  errors  spawned  by  changes  or  corrections  made  during  software  development 
and  maintenance.  p<CASE]  Selective  retesting  to  detect  faults  introduced  during 
modifications  of  a  system  or  system  comptmott,  to  verify  that  nrodifications  have  not 
caused  unintended  adverse  effects,  or  to  verify  that  a  modified  system  or  system 
component  still  meets  its  specified  requirements. 

Relational  database.  A  database  that  allows  the  linking  of  different  pieces  of 
information.  [SWTP] 

Relational  database  management  system  (rdbms).  A  database 
management  system  in  which  information  is  organized  in  tables.  p-CAS^ 

Relationship.  An  association  between  two  entity  types.  p-CASE] 

REUABiurY.  The  ability  of  an  item  to  perform  a  required  function  under  stated 
conditions  for  a  stated  period  of  time.  PXTT]* 

Repository.  (1)  The  place  where  the  software  artifacts  are  kept  in  their  on-line 
form.  Its  functions  are  modeled  after  those  of  a  librarian;  it  is  the  gatekeeper  of 
project  products.  Artifacts  are  typically  created  and  modified  outside  the  realm  of  the 
repository.  [SWTP]  (2)  The  mechanism  for  defining,  storing,  accessing,  and 
managing  all  of  the  information  about  an  mteiprise,  its  data,  and  its  software  systems. 
P^CC] 

Requirements  analysis.  (1)  The  process  of  studying  user  needs  to  arrive  at  a 
definition  of  system,  hardware,  or  software  requirements  (referred  to  as  the 
Requirements  Analysis  Phase).  (2)  The  process  of  studying  and  refining  system, 
hardware,  or  software  requirements.  p-CASE] 

Requirements  engineering.  Involves  all  life-cycle  activities  for  identifying 
user  requirements,  analyzing  the  requirements  to  derive  additional  requirements, 
documenting  the  requirements  as  a  specification,  and  validating  the  documented 
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requirements  against  user  needs.  Also  refers  to  processes  dut  supptvt  these  activities. 
[STS] 

Requirements  traceability.  Checking  to  ensure  that  user  requirements  are 
satisfied  by  the  software  system  being  inoduced  and  that  all  software  being  produced 
can  be  traced  back  to  a  requirement.  [1-CASE] 

Reusable  software.  Software  that  has  application,  in  whole  or  in  part,  to 
more  than  one  specific  function.  [DOD-STD-2167A] 

Reuse  library,  (l)  A  library  that  contains  filtered  items  ftom  many  inojects, 
usually  within  the  same  domain.  A  reuse  library  has  a  different  schema  and  tooling 
than  a  data  repository.  It  usually  contains  larger  grain  data.  (2)  Storage  locaticm  for 
software  developed  in  response  to  the  requirements  for  one  iq)plication  than  can  be 
used,  in  whole  or  in  part,  to  satisfy  the  requirements  of  another  aiq)lication. 
[DOD<STD-2167A]  (3)  A  central  library  of  reusable  software  parts  that  is  available 
to  software  developers.  [DORF] 

Reverse  engineering.  Ttie  process  of  analyzing  a  subject  system  to  identify 
the  system’s  components  and  their  interrelationships  and  create  iq)resentations  of  the 
system  in  another  form  or  at  a  higher  level  of  abstraction.  [I-CASE] 

Risk.  The  probability  of  occurrence  of  an  undesired  event  and  its  impact. 
[SWTP] 

Risk  analysis.  The  process  of  idoitifying  risks,  determining  their  magnitude, 
and  identifying  -eas  needing  saf^uards.  Risk  analysis  is  a  part  of  risk  management 
and  is  synonymous  with  risk  assessment  [I-CASE] 

Risk  assessment.  Information  provided  to  identify  items  at  risk,  thdr  sources  of 
risk,  and  their  measure  of  risk.  Risk  assessment  is  accomplished  through  a 
disciplined  and  structured  process  to  systematically  identify  and  analyze  risks. 
[SWTP] 

Risk  management.  Making  informed  decisions  by  cmisciously  assessing  what 
can  go  wrong  and  the  resulting  impact  Risk  numagement  is  accomplished  through 
a  continuous  set  of  activities  to  identify,  confront,  and  resolve  risks.  [SWTP] 

Robustness.  The  extent  to  which  software  can  continue  to  operate  correctly 
despite  the  introduction  of  invalid  inputs.  [IEEE] 
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RUN-TIME  ENvntoNMENT.  The  envinximent  in  which  i^lications  produced 
using  the  I-CASE  environment  will  operate.  [I-CASE] 

Safe  softwake.  Software  that  has  a  level  of  assurance  that  the  sy^em  will  not 
enter  a  hazardous  state.  If  a  hazardous  state  should  occur,  the  system  will  get  out  of 
it.  A  hazardous  state  is  one  in  which  an  accident  or  mishap  can  occur  (e.g.,  when 
two  aircraft  come  closer  than  the  prescribed  safe  distance).  [SWTP] 

Scaffolding.  Temporary  code  that  has  been  developed  to  interface  with  tme  or 
more  modules.  This  temporary  code  allows  modules  to  be  independently  tested  while 
waiting  for  the  permanent  interfacing  modules  to  be  developed  and  readied  for  use. 

Scheduler.  The  part  of  a  real-time  system  that  performs  task  management. 
[SWTP] 

SCHEDUUNO  ALGORITHM.  A  set  of  rules  that  assigns  the  time  at  which  each  task 
will  receive  service.  [SWTP] 

Secure  software.  Software  that  has  a  level  of  assurance  that  the  system  can 
enforce  a  specific  security  policy.  [SWTP] 

Sensor.  (1)  Equipment  that  detects  and  may  indicate  and/or  record  objects  and 
activities  by' means  of  energy  or  particles  emitted,  reflected,  or  modifled  by  objects. 
[IEEE]  (2)  Equipment  that  detects  and  indicates  terrain  configuration,  the  presence 
of  military  targets,  and  other  natural  and  fabricated  objects  and  activities  by  means 
of  energy  reflected  or  emitted  by  such  targets  or  objects.  The  energy  may  be  nuclear, 
electromagnetic  (including  the  visible  and  invisible  portions  of  the  spectrum), 
chemical,  biological,  thermal,  or  mechanical  (including  sound,  blast,  and  earth 
vibration).  [SWTP] 

Simulation.  The  representation  of  selected  characteristics  of  the  behavior  of 
one  physical  or  abstract  system  by  another  system.  In  a  digital  computer  system, 
simidation  is  done  by  software;  for  example,  (a)  the  represmitation  of  physical 
phenomma  by  means  of  operations  performed  by  a  computer  system,  (b)  the 
rqrreseitation  of  operations  of  a  computer  system  by  those  of  another  computer 
system.  [IEEE] 

Soft  real-time  system,  a  system  in  which  a  statistical  distribution  of  task 
service  times  is  acceptable.  [SWTP] 

Software.  Computer  program  instructions  and  data. 
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Software  architecture.  The  structure  and  relatitmships  among  the 
components  of  software.  [IEEE] 

Software  bridge.  Software  that  translates  from  ont  protocol  to  another. 
[SWTP] 

Software  bug.  A  software  fault.  [SWTP] 

Software  development  cycle.  (1)  The  period  of  time  that  b^ins  with  the 
to  develop  a  software  product  and  ends  when  the  product  is  delivered.  This 
cycle  typically  includes  a  Requirements  Phase,  Design  Phase,  Implementatitm  Phase, 
Test  Phase,  and  sometimes.  Installation  and  Checlqpoint  Phase,  contrast  with  software 
life  cycle.  (2)  The  period  of  time  that  begins  with  the  decision  to  devdop  a  software 
product  and  ends  when  the  product  is  no  longer  being  enhanced  by  the  develq)er. 
(3)  Sometimes  used  as  a  synonym  for  software  life  cycle.  See  product  development 
cycle.  [IEEE] 

Software  development  file.  An  electronic  or  paper  repository  for  a 
collection  of  material  pertinent  to  the  development  or  support  of  software.  Contents 
typically  include  (either  directly  or  by  reference)  design  considerations  and 
constraints,  design  documentation  and  data,  schedule  and  status  information,  test 
requirements,  test  cases,  test  procedures,  and  test  results.  [DOD-STD-2167A] 

Software  engineering.  (1)  The  application  of  science  and  mathematics  by 
which  the  capabilities  of  computer  equipment  are  made  useful  through  computer 
programs,  procedures,  and  associated  documentation.  (2)  The  application  of  a 
systematic,  disciplined  approach  to  the  development,  operation,  and  maintenance  of 
software;  (i.e.,  the  application  of  engineoing  to  software).  [IEEE]  (3)  A  science  of 
design,  development,  implementation,  test,  evaluation,  and  maintenance  of  computer 
software  over  its  life  cycle.  [DODD] 

Software  engineering  environment  (see).  A  collection  of  hardware  and 
software  tools  enveloped  in  a  process  to  mgineer  software.  [I-CASE] 

Software  life  cycle.  (1)  The  period  of  time  that  starts  when  a  software 
product  is  conceived  and  ends  when  the  product  is  no  longer  available  for  use.  The 
software  life  cycle  typically  includes  a  Requirements  Phase,  Design  Phase, 
Implementation  Phase,  and  sometimes.  Maintenance  and  Retirement  Phases.  Contrast 
with  software  development  cycle.  [lEE^  (2)  The  series  of  steps  or  phases  through 
which  the  software  progresses,  usually  from  conception  to  retiremait.  [I-CASE] 
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Software  maintainability.  The  probability  that  the  software  can  be  retained 
in  or  restored  to  a  specified  status  in  a  pr^cribed  period  compatible  with  missitm 
requirements. 

Software  process.  The  sequence  of  tasks  and  management  techniques  used 
during  the  creation  and  evolution  of  software  systems.  [SWTP] 

Software  product  metrics.  The  collection  of  data  and  analysis  from 
software  products  for  purposes  of  estimating  (a)  the  quality  of  the  products  at  each 
phase  of  the  software  development  cycle,  (b)  the  reliability  of  the  software,  and  (c) 
the  size  of  the  software.  [SWTP] 

Software  quality.  The  ability  of  a  software  product  to  satisfy  its  specific 
requirements.  [DOD-STD-2168] 

Software  reengineering.  (1)  The  examination  and  alteration  of  a  software 
system  to  reconstitute  it  in  a  new  form  and  the  subsequent  implmnentation  of  the  new 
form.  [IEEE]  (2)  Reengineering  requires  understanding  the  design  of  existing 
software  that  was  written  in  an  undisciplined,  ad  hoc  style  and  then  describing  the 
design  in  a  structured  form  consistent  with  modem  software  engineering  methods. 
[SWTP] 

Software  reuse.  (1)  The  deliberate  ocploitation  of  existing  software 
components  and  related  assets  to  facilitate  the  development  of  new  software  systems. 
[SWTP]  (2)  The  ability  to  use  existing  software  components  over  and  over.  Reuse 
is  facilitated  by  the  use  of  an  I-CASE  repository  in  which  reusable  software 
components  can  be  stored.  Software  componmits  can  consist  of  requirements,  design, 
code,  data,  and  data  models.  [I>CAS^ 

Software  reuse  technology.  (1)  Processes,  architectures,  and  component 
composition  capabilities  that  facilitate  software  reuse.  (2)  The  organization,  storage, 
and  management  of  reusable  components  into  repositories.  (3)  The  casual  browsing 
and  systematic  searching  of  these  repositories  to  locate  potentially  useful  components. 
(4)  llie  modification  and  integration  of  the  componoits  into  the  evolving  system 
d^elopment  [SWTP] 

Software  tool,  a  computer  program  used  to  help  develop,  test,  analyze,  or 
maintain  another  computer  program  or  its  documentation  (e.g. ,  automated  design  tool, 
compiler,  test  tool,  and  maintenance  tool).  [IEEE] 
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Softwake  upgrade.  Software  changes  that  are  made  to  include  significant 
enhancements  and  new  features  that  improve  the  performance  and  aq>ability,  or  other 
attributes,  of  a  software  product.  Normally,  software  upgrades  are  provided  to  a 
commercial  customer  at  a  cost  in  addition  to  the  original  purchase  price.  p-CASE] 

Source  lines  of  code  (sloc).  The  count  of  program  instructions  created  by 
project  personnel,  excluding  comment  lines.  [I~CASE] 

Specihcation.  (1)  A  document  that  prescribes,  in  a  complete,  precise,  verifiable 
manner,  the  requirements,  design,  b^vior,  or  other  char^teristics  of  a  system  or 
system  component.  (2)  The  process  of  developing  a  specification.  (3)  A  concise 
statement  of  a  set  of  requirements  to  be  satisfied  by  a  product,  a  material,  or  process 
indicating,  whenever  appropriate,  the  procedure  by  means  of  which  it  may  be 
determined  whether  the  requirements  given  are  satisfied.  PEEE] 

SQL  (structured  query  language).  A  standard  relational  database 
language.  p-CASE] 

Standard.  An  approved,  documented,  and  available  set  of  criteria  used  to 
determine  the  adequacy  of  an  action  or  object. 

Standard  data  element.  A  data  element  that  is  an  Air  Force  standard  (i.e., 
included- in  the  Air  Force  Corporate  Data  Dictionary).  p*CASE] 

Structure  chart.  A  diagram  that  identifies  modules,  activities,  or  other 
entities  in  a  system  or  computer  program  and  shows  how  larger  or  more  general 
entities  break  down  into  smaller  more  specific  entities.  (Synonyms:  hierarchy  chart, 
program  structure  chart).  p-CASE] 

System  specihcation.  A  system-level  specification.  The  system  specification 
may  be  a  System/Segment  Specification  (SSS)  (DOD-STD-2167A)  or  a  Design  Unit 
Specification  (DUS).  [AFC^M2  Guidelines  Handbook] 

System  performance  analysis.  Measures  the  performance  of  computer 
systems  and  investigates  methods  by  which  that  performance  can  be  improved. 
P-CASE] 

System  test.  A  test  of  a  product  in  a  total  systems  environment  with  other 
software  and  hardware  product  combinations. 

Tailor.  To  modify  or  change  a  set  of  standards  or  procedures  to  better  match 
process  or  product  requirements.  [SWTP] 
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Taex>RING.  (1)  Usually  spoken  of  or  referring  to  acquisition  strat^y, 
allows  the  CDRL  item  to  be  written  to  suit  an  individual  program’s  needs.  No  strict 
format  needs  to  be  followed.  Basics  must  be  addressed,  but  the  Program  Manager 
has  authority  to  design  or  plan  for  specific  requirements  to  meet  the  optimum  balance 
between  need  and  cost.  Tailoring  allows  flexibility.  (2)  The  process  by  which 
individual  requirements  of  standards,  DID,  and  related  documents  are  evaluated  to 
determine  their  suitability  for  a  specific  software  production  effort,  and  the 
modification  of  those  requirements  to  ensure  that  each  achieves  an  optimal  balance 
between  operational  needs  and  costs.  [DOD-HDBK-287A] 

Task.  (1)  A  piece  of  work  assigned  to  a  person  or  group  of  persons  [Webster]. 
(2)  In  an  executing  software  system,  a  software  entity  Aat  performs  a  particular 
functicyn.  Also,  the  unit  of  work  in  the  software  process  that  provides  a  visible 
management  checkpoint.  Tasks  have  entry  criteria  (preconditions)  and  exit  criteria 
(post  conditions).  [SWTP] 

Taxonomy.  The  general  principles  of  scientific  classification.  [SWTP] 

Technology  refreshment.  An  addition  or  substitution  (i.e.,  a  new 
component),  upgrade,  or  update  to  the  I-CASE  environment  product  baseline 
(hardware  and  software).  [I-CASE] 

*Pemplate.  -  A  predefined  outline  that  serves  as  a  pattern  for  document 
generation  or  data  input.  [I-CASE] 

Testing.  The  process  of  exercising  or  evaluating  a  system  or  system  component 
by  manual  or  automated  means  to  verify  that  it  satisfies  tqiecified  requirements  or  to 
identify  differences  between  expected  and  actual  results.  [IEEE] 

Total  quality  management  (tqm).  (1)  The  DOD  version  of  a  management 
strategy  designed  to  ensure  quality  with  regard  to  the  performance  of  management, 
personnel,  and  product.  The  concept  originates  in  the  work  of  Doming  and  Juran. 
[SWTP]  (2)  A  management  ilosophy  committed  to  a  focus  on  continuous 
improvement  of  product  and  services  with  the  involvement  of  the  entire  workforce. 

Traceability.  The  degree  to  which  a  relationship  can  be  established  between 
two  or  more  products  of  the  development  process,  especially  products  having  a 
predecessor-successor  or  superior-subordinate  relationship  to  one  another.  [IEEE] 

Training.  The  level  of  learning  required  to  adequately  perform  the 
responsibilities  designated  to  the  function  and  accomplish  the  mission  assigned  to  the 
system. 
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Transverse  engineerino.  The  coinbin:.';on  of  revent  engineering,  insertion 
of  design  changes,  and  forward  engineeri'  performed  in  that  order.  p-CASE] 

Troian  hopse.  (1)  A  program  that  appears  to  do  something  useful,  yet 
additionally  does  something  destructive  behind  one’s  back.  P-CASE]  (2)  A  computer 
program  with  an  apparc  :ly  or  actually  useful  function  that  ctmtains  additional 
(hidden)  functions  that  surreptitiously  exploit  the  legitimate  authorizations  of  the 
invoking  process  to  the  detriment  of  security  or  integrity.  p-CASEj  See  also  Virus 
and  Worm. 

Ultra-critical  software.  Software  that  is  required  to  provide  service  with  an 
extremely  low  probability  of  failure  (e.g.,  lO*’  failures/hour).  [SWTP] 

Untt  Test.  The  isolated  testing  of  each  flow  path  of  code  within  each  module. 

I  R  friendly,  a  basic  characteristic  of  a  product  that  simplifies  its  operation 
for  users  and  assists  users  in  understanding  other  in-oduct  functions.  This  "ease  of 
use”  condition  is  typically  attributed  to  the  quickness  with  which  users  can  both  learn 
and  become  productive  with  a  product. 

Utoity.  The  state  or  quality  of  being  useful  militarily  or  operationally. 
Designed  for  or  possessing  several  useful  or  practical  purposes  rather  than  a  single, 
specialized  one. 

Validation.  (1)  The  process  of  evaluating  software  at  the  end  of  the  software 
development  process  to  ensu;  compliance  with  software  requirements.  [IEEE]  (2) 
The  process  of  evaluating  oftware  to  determine  compliance  with  specified 
requirements.  [DOD-STD-2.o7A] 

Verification.  (1)  The  process  of  determining  whether  the  products  of  a  given 
phase  of  the  software  development  cycle  fulfill  the  requirements  established  during 
the  previous  phase.  (2)  Formal  proof  of  program  correctness.  [IEEE]  (3)  The  act 
of  reviewing,  inspecting,  testing,  checking,  auditing,  or  otherwise  establishing  and 
documenting  whether  items,  processes,  services,  or  documents  conform  to  specified 
requirements.  [DCT]  (4)  The  process  of  ev^uating  the  products  of  a  software 
development  activity  to  determine  the  correctness  and  consistency  with  respect  to  the 
products  and  standards  provided  as  input  to  that  activity.  [DOD-STD-2167A] 

Virtual  reality.  Computationally  obtained  representations  of  reality  (e.g.,  use 
of  special  input  and  output  devices  such  as  head-mounted  displays)  that  create  for  any 
operator  the  illusion  of  a  real  world  in  which  the  operator  can  move  and  function  in 
a  natural  fashion.  [SWTP] 
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Virus,  (1)  A  piece  of  code  that  attaches  itself  to  other  programs.  Once  an 
infected  program  is  run,  the  virus  quickly  spreads  to  system  files  and  other  software. 
(2)  A  self-propagating  Trojan  horse,  composed  of  a  mission  component,  a  trigger 
component,  and  a  self-propagating  component.  p-CASE]  (See  also  Trojan  Horse  and 
Worm) 

Waiver.  A  written  authorization  to  acc^t  an  item  that,  during  production  or 
after  having  been  submitted  for  inspection,  is  found  to  depart  from  the  specified 
requirements,  but  nevertheless  is  considered  suitable  for  use  as  is  or  after  rework 
by  an  approved  method.  p-CASE] 

Walkthrough.  A  technique  used  to  review  the  design  and  code  of  a 
production  effort,  which  can  be  conducted  throughout  the  software  production 
process.  p-CASE] 

Work  breakdown  structure  (wbs).  A  project-oriented  family  tree, 
composed  of  hardware,  software,  services,  and  other  work  tasks,  which  results  from 
project  engineering  effort  during  the  development  and  production  of  a  Defense 
material  item,  and  which  completely  defines  the  project/program.  A  WBS  displays 
and  defines  the  product  (s)  to  be  developed  or  produced  and  relates  elements  of  work 
to  be  accomplished  to  each  other  and  to  the  end  product.  p-CASE] 

Worm.  A  program  that  replicates  and  spreads,  but  does  not  attach  itself  to  other 
programs.  Unlike  a  virus,  it  does  not  require  a  host  to  survive  and  replicate.  Worms 
usually  spread  within  a  single  computer  or  over  a  network  of  computers.  They  are 
not  spread  through  the  sharing  of  programs.  (See  also  Trojan  Horse  and  Virus). 
P-CASE] 


( 
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